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explore  conducting  military  deception,  focusing  on  the  use  of  software- driven 
simulations  to  respond  to  the  actions  of  intruders.  In  particular,  this  thesis  focuses  on  a 
model  of  a  simple  deceptive  response  that  is  intended  to  protect  a  search- type  program 
from  a  buffer- overflow  attack.  During  our  study,  we  found  that  after  identifying  an 
attack  attempt,  simulating  system  saturation  with  processing  delays  worked  well  to 
deceive  a  prospective  attacker.  We  also  experimented  with  providing  confusing  reactions 
to  an  identified  attack  attempt,  such  as  simulated  network  login  screens  and  fake  root- 
shells.  The  results  were  successful,  simple  reactions  to  intrusions  that  mimicked  intended 
system  interaction,  and  they  proved  to  be  adequate  at  implementing  the  deception 
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I.  INTRODUCTION  AND  SCOPE 


A.  INTRODUCTION 

In  the  modem  world  of  integrated  computer  communications,  intrusion  detection 
has  become  vital  to  the  overall  security  of  the  individual  networks.  IVhny  intrusion- 
detection  systems  have  been  developed  and  implemented  to  detect  anomalous  behavior. 
Firewalls,  system  logs,  and  virus  detection  have  all  been  effective  in  identifying  attack 
protocols  and  preventing  potential  intrusions.  The  usual  response  to  these  intrusions  is  a 
notification  to  the  system  administrator  or  filtering  out  of  the  network  the  source  of  the 
anomalous  behavior.  But  what  if  information  can  be  gained  by  allowing  the  intrusion  in 
a  controlled  manner?  Controlling  the  intrusion  can  be  accomplished  by  crafting  a 
response  to  a  detected  intrusion. 

Two  main  levels  of  response  are  currently  being  explored.  First,  a  low-level 
automated  response  using  system-call  delays  is  examined  by  Somayaji  and  Forrest  in  [6] 
as  a  way  to  allow  an  attacked  computer  to  preserve  its  own  integrity.  The  concept 
ignores  the  source  and  method  of  the  intrusion  and  instead  focuses  on  helping  the 
affected  system  maintain  a  stable  state.  In  contrast,  Michael  and  Riehle  have  proposed  an 
intelligent  software  decoy  to  deceive  the  attacker  while  maintaining  system  stability  [1], 
They  define  an  intelligent  software  decoy  as  an  object  with  a  contract  for  which  a 
violation  of  one  or  more  preconditions  by  an  agent  causes  the  object  to  try  to  both 
deceive  the  agent  into  concluding  that  its  violation  of  the  contract  has  been  successful  and 
assess  the  nature  of  the  violation,  while  enforcing  all  postconditions  and  class  invariants 
[1].  In  other  words,  they  propose  taking  intrusion  detection  one  step  further  by 
implementing  intelligent  responses  and  deception. 


B.  BACKGROUND 

Computer  security  can  be  thought  of  as  a  silent  alarm  system  that  encompasses  a 
computer  network.  Mechanisms  should  always  be  in  place  to  protect  the  network,  and  to 
respond  to  a  possible  attack  efficiently.  Computer  security  is  a  process.  As  discussed  by 
Wadlow  in  [2],  the  process  can  be  applied  again  and  again  to  improve  the  security  of  the 
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system.  Wadlow  compares  the  process  of  security  to  the  ancient  Greek  triad- engineering 
model  of  Analyze,  Synthesize,  and  Evaluate,  as  pictured  below. 


Figure  1.1  The  Greek  Triad  Model 

The  success  of  the  process,  though,  depends  on  the  ability  to  synthesize  and  implement 
the  ideas  and  concepts  learned  through  the  analysis  of  the  network.  This  forces  the  need 
to  gain  as  much  knowledge  as  possible  about  possible  computer- network  attacks  in 
particular. 

Current  intrusion-detection  systems  gain  information  about  attacks  and  attack 
profiles,  but  they  fall  short  at  being  dynamically  adaptable  and  truly  intelligent  about 
their  response  to  the  attack.  Most  systems  are  capable  of  terminating  connections,  killing 
processes,  and  blocking  certain  messages  from  the  network.  As  with  most  security 
devices,  though,  in  practice  these  mechanisms  cannot  be  widely  deployed  because  of  the 
threat,  or  risk,  of  false  and  inappropriate  responses.  Somayaji  and  Forrest  suggest  that 
the  intrusion  detection  systems  become  too  much  of  a  burden  to  effectively  analyze  and 
respond  to  anomalies  because  of  the  overhead  associated  with  human  analysis  [6].  It 
follows  that  an  intelligent  and  autonomous  solution  is  needed  not  only  to  protect  the 
network,  but  also  to  gain  information  about  current  attacking  techniques. 
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C.  SCOPE 


Our  research  focuses  on  exploring  the  level  of  response  that  is  appropriate  for  an 
intelligent  software  decoy.  We  study  three  levels  of  response:  simple,  intermediate,  and 
complex.  Each  level  has  unique  development  issues  currently  being  explored,  but  they 
all  relate  back  to  the  process  of  engineering  the  software  decoy.  The  simple  level  of 
response  seeks  to  exaggerate  affects  on  the  system  caused  by  malicious  use.  By  contrast, 
intermediate- level  responses  seek  to  respond  to  an  attack  by  mimicking  a  previous  attack. 
Finally,  a  complex- level  response  could  simulate  a  successful  attack  on  an  entire 
computer  system  or  network. 

This  thesis  is  limited  to  three  primary  tasks:  discussing  the  concept  of  a  software 
decoy,  defining  the  levels  of  complexity  of  the  responses,  and  examining  the  practicality 
of  a  decoy  through  the  development  of  a  model  of  a  simple  response.  After  we  define 
each  level  of  response,  we  develop  a  simple  response  model  based  on  a  Java  Servlet 
program  defending  against  a  buffer  overflow  attack.  By  developing  this  proof- of- concept 
model,  we  hope  to  gain  valuable  insight  into  the  development  of  more  complex  and 
functional  software  decoys. 
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II.  DEVELOPMENT  OF  INTELLIGENT  SOFTWARE  DECOYS 


A.  BACKGROUND 

With  the  always- increasing  dependence  on  computer  systems  and  computer 
networks  in  today’s  society,  application  possibilities  are  limitless.  Unfortunately,  the  risk 
of  malicious  use  and  information  compromise  is  also  increasing.  Modem  computer 
systems  must  be  designed  to  prevent  unauthorized  access  to  the  resources  and  data  they 
contain. 

Intrusion  can  be  defined  as  a  deliberate  attempt  to  gain  access  to  unauthorized 
information,  to  change  or  manipulate  information,  or  to  make  a  system  unstable  and 
unusable.  All  are  attempts  to  degrade  the  computer  system’s  to  provide  for  desired 
levels  of  confidentiality,  integrity,  availability,  and  other  security  properties. 

While  intrusion- detection  systems  have  been  studied  exhaustively,  they  are  still 
reactive  rather  than  pro-active  to  intrusions.  For  instance,  one  of  the  most  popular  and 
widely  used  ways  that  intrusions  are  detected  is  through  audit-trail  use.  This  involves 
studying  each  event  that  happens  on  a  system  as  recorded  through  the  continuous  logging 
of  events.  The  amount  of  data  collected  per  day  could  be  quite  large,  especially  if  one 
instruments  a  system  to  monitor  many  events  that  occur  on  a  frequent  basis.  Software, 
however,  has  been  developed  to  allow  the  quick  studying  of  events  and  to  look  for 
anomalous  behavior.  The  two  main  ways  to  discover  an  intrusion  are  anomaly 
identification  and  misuse  detection. 

1.  Anomaly  Identification 

Behavior  in  a  computer  system  can  be  best  described  by  defined  functionality  of  a 
user  within  a  system.  Each  user  has  pre- defined  rules  that  govern  their  actions  while  a 
member  of  that  computer  domain.  These  rules  are  based  on  statistical  profiles  that  are 
developed  for  individual  computer  users  [13].  The  current  behavior  of  the  user  is  then 
compared  with  recorded  behavior  to  determine  whether  it  is  normal.  Identification  of 
anomalies  can  potentially  recognize  unforeseen  attacks,  although  it  is  not  foolproof. 
Anomaly  identification  can  be  limited  by  vague  rules  which  make  it  difficult  to 
distinguish  between  normal  and  abnormal  behavior. 
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For  example,  a  trusted  user  may  have  the  privilege  to  modify  a  particular  file, 
while  an  untrusted  user  who  is  accessing  the  file  over  a  network  connection  may  only 
have  permission  to  read  the  file.  In  this  case,  an  anomaly  would  occur  if  the  untrusted 
user  tried  to  modify  or  change  the  permissions  of  the  file  to  give  him  access  so  he  can 
then  modify  the  contents. 

2.  Misuse  Detection 

Intrusions  can  be  described  in  terms  of  the  indications  and  signs  they  leave  behind 
on  the  system.  Misuse  is  based  on  expert  knowledge  of  patterns  associated  with 
unauthorized  use  or  activity  [13].  These  patterns,  sometimes  called  signatures,  are 
compiled  and  then  implemented  into  detection  programs  that  find  a  match  between  a 
signature  and  current  activity.  Pattern  analysis  can  also  be  used  to  study  logs  and  system- 
audit  information.  Once  a  pattern  is  identified  in  the  logs,  it  can  be  described  abstractly 
to  allow  its  recognition  in  the  future. 

The  principles  employed  with  intrusion  detection  systems  are  widely  used  today 
to  protect  information  systems.  They  supplement  tools  such  as  firewalls,  encryption,  and 
authentication. 

B.  DECEPTION  PRINCIPLES 

Sun  Tzu  makes  a  simple  yet  profound  statement  in  The  Art  of  War  that  “All 
warfare  is  based  on  deception” [8].  An  argument  certainly  can  be  made  that  computer 
security,  and  indeed  information  assurance,  is  a  part  of  future  warfare.  Can  deception 
help  protect  systems?  Can  it  encourage  an  enemy’s  arrogance  by  feigning  a  poorly 
protected  computer  network? 

Deception  fundamentals  are  provided  from  other  basic  military  operational 
techniques.  The  following  are  the  six  basic  rules  of  deception  that  could  be  applied  to 
computer  deception  [7].  We  also  include  two  other  basic  concepts  of  deception  and 
cheating  discussed  in  [9]:  hiding  and  showing. 
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1.  Believability 

The  effectiveness  of  deception  is  first  based  on  the  ability  to  have  the  enemy 
believe  what  he  is  experiencing  is  real.  That  is,  to  make  an  action  appear  to  coincide  with 
the  enemy’s  preconceived  notion  of  the  expected  results.  For  computer  security,  the 
enemy  is  the  malicious  user  who  is  attempting  to  access  a  system  without  the  proper 
permissions.  To  make  the  deceptions  successful,  the  malicious  user  must  believe  he  is 
accessing  the  system.  The  correct  simulated  reaction  to  attacker  input,  generated 
directories  that  appear  to  have  accepted  malicious  code,  and  appropriate  delays  to 
simulate  compilation  may  make  the  simulation  of  a  computer  attack  believable. 

2.  Timely  Feedback 

Timely  feedback  is  an  essential  element  of  all  major  deceptions.  It  is  important  to 
observe  the  reaction  to  any  deceptive  activity  because  if  the  attacker  does  not  accept  the 
deception,  the  system  running  the  simulation  may  be  vulnerable.  In  an  autonomous 
intrusion-detection  system,  real-time  observation  is  delegated  to  the  logic  of  the  detection 
program.  This  allows  observation  of  the  reaction  to  the  deceptive  activities.  To  make 
this  feedback  effective  for  an  intrusion-detection  system,  a  good  study  of  what  beliefs  and 
biases  are  built  into  the  attacker  culture  is  necessary  to  improve  the  likelihood  that  one 
has  created  the  correct  deception  to  anticipate  the  reaction  with  little  error.  This  includes 
a  study  of  the  timeliness  of  actual  deceptive  activities.  If  a  computer  simulation  reacts 
too  quickly  or  too  slowly  the  activity  may  not  fool  the  attacker.  Therefore,  the  simulation 
of  system  effects  of  an  attack  must  occur  in  accordance  with  the  time  the  attacker 
expects. 

3.  Integration 

The  plan  for  deception  should  be  integrated  with  the  goals  of  the  operation;  in 
particular  the  normal  processing  of  a  computer  system  should  include  the  well- formed 
plan  for  deception.  The  operation  and  deception  plans  must  be  mutually  supportive  and 
should  complement  each  other.  This  will  not  allow  for  ad-libbed  deceptive  operations 
that  have  been  shown  to  be  counterproductive  [7].  When  the  deception  is  integrated 
properly  into  the  operational  plan,  the  overall  effect  will  provide  believable  indicators  of 
the  false  operations  and  will  deny  believable  indicators  of  the  real  operation.  Integrating 
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the  deception  within  the  software  of  a  system,  as  opposed  to  using  a  separate  Honeypot- 
type  system  [18],  may  allow  for  a  more  effective  way  to  use  computers  to  protect 
themselves  against  attacks  vice  dedicating  separate  networks  to  catch  and  analyze 
intrusions. 

4.  Denial  of  True  Activities 

The  deception  must  be  stealthy  and  should  protect  the  true  activities.  In  computer 
system  terms,  a  carefully  constructed  software-based  deception  could  effectively  deceive 
an  attacker,  but  only  if  the  attacker  does  not  receive  contradictory  information  from  the 
real  activity  of  the  system.  One  way  to  suppress  the  actual  operating  system  functionality 
would  be  to  isolate  the  attacker  so  he  has  no  ability  to  interact  with  the  real  operating 
system.  Isolating  the  attacker  in  the  software  is  accomplished  by  coordinating  system 
delays  in  the  place  of  actual  system  interaction.  Another  way  to  protect  the  true  activities 
of  a  computer  system  is  to  portray  the  time  a  process  takes  to  complete  while  not  actually 
performing  the  task.  For  instance,  if  a  search  program  takes  a  certain  amount  of  time  to 
accomplish,  then  a  simulation  of  that  search  should  delay  the  user  for  that  same  time. 
Delays  can  be  used  effectively  to  simulate  system  interaction  thereby  denying  the  actual 
activity  of  the  computer. 

5.  Realistic  Response 

Deception  should  be  a  function  of  the  level  of  response  desired  to  ensure  the 
proper  degree  of  realism.  There  sho  uld  be  a  level  of  deception  that  is  proportional  to  the 
time  that  is  needed  to  analyze  a  situation  and  take  appropriate  action.  For  example,  if  an 
attacker  is  simply  attempting  to  launch  a  denial  of  service  program  on  a  system,  it  may  be 
sufficient  only  to  delay  for  the  amount  of  time  it  takes  to  compile  the  program.  It  may 
not  be  necessary  to  carry  the  deception  past  the  simple  delay.  However,  if  an  attacker 
tries  to  place  a  root  kit  program  on  a  target,  it  would  be  necessary  to  simulate  a  root- shell 
screen  with  input  and  output  capabilities.  The  root- shell  should  also  be  supported  by  a 
simulated  complex  file-system  to  make  the  response  as  realistic  and  believable  as 
possible. 
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6.  Imagination 

History  has  shown  that  the  most  successful  deceptions  have  been  imaginative  and 
creative.  When  a  deception  becomes  too  predictable  or  stereotyped,  the  effectiveness 
may  be  compromised.  Standard  deceptive  responses  should  not  be  developed  and  should 
not  imply  the  development  of  a  capability  that  has  not  been  realized.  Deception  is  best 
accomplished  by  utilizing  inventive  and  bright  ideas.  Imaginative  computer  deceptions 
can  include  creative  error  messages,  generated  file  systems  that  are  viewable  to  the 
attacker,  and  the  appearance  of  new  interactions.  The  deceptions  should,  however, 
follow  along  with  what  is  expected  to  ensure  the  believability  of  the  simulation.  On  the 
other  hand,  if  an  attacker  finds  he  is  presented  with  an  unexpected  way  to  gain  access  to  a 
computer  system,  he  may  be  more  inclined  to  attempt  a  breach.  Some  other  creative 
ways  to  keep  an  attacker’s  attention  could  be  to  present  file  systems  that  are  seemingly 
retrievable,  simulate  the  allowance  of  an  attacker  to  place  files  on  a  system  then  modify 
them,  and  also  to  create  an  environment  that  simulates  root- access  that  is  receptive  to 
input  and  output.  The  imagination  of  the  simulation  programmer  is  unlimited,  and  the 
development  of  software  can  support  nearly  any  kind  of  simulation. 

7.  Hiding 

According  to  [9],  the  psychology  of  deception  uses  two  basic  concepts  of  the 
devices  found  in  nature.  The  first  concept,  hiding,  fulfills  the  basic  purpose  of  deception 
to  screen  the  thing  you  mean  to  protect.  Altering  and  covering  the  particular  details  of 
the  thing,  in  our  case  a  computer  system,  can  be  used  to  gain  some  advantage  over  a 
potential  adversary.  For  example,  we  can  hide  an  important  file  on  a  computer  system  by 
saving  the  file  under  a  different  name  among  some  other  bogus  files  with  non- descriptive 
names.  Hiding  computer  system  information  can  also  be  thought  of  much  like  hiding  a 
submarine  in  a  vast  ocean.  Software  decoys,  in  general,  will  avoid  hiding  themselves  on 
a  system,  but  they  can  be  used  to  hide  the  actual  operating- system  functions.  For 
example,  decoys  can  hide  the  fact  that  they  are  delaying  a  user,  to  simulate  system 
interaction,  by  mimicking  what  really  happens  when  a  user  interacts  with  an  operating 
system. 
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8.  Showing 

Showing  is  a  deception  where  an  altered  truth  is  presented.  There  are  three  ways 
to  show  the  false:  by  mimicking,  inventing,  or  decoying.  A  replica  of  reality  is  created 
by  selecting  one  or  more  characteristics  of  the  real  to  achieve  an  advantage  when 
mimicking  [9].  There  are  many  classic  military  examples  of  mimicking.  For  instance, 
the  Germans  during  World  War  I  portrayed  to  the  Belgians  that  their  force  was  more  than 
150,000  troops  when  it  was  indeed  less  than  20,000.  The  German  mimic  was  a  success 
because  there  was  an  extended  period  of  time  when  the  illusion  was  not  revealed, 
allowing  them  to  gain  an  advantage.  Mimicking  with  software  is  accomplished  with  a 
Honey  Pot-type  system  that  pretends  to  be  an  unprotected  computer  system  or  network 
and  seems  to  be  easier  prey  for  intruders  than  true  production  systems  with  minor  system 
modifications  [20]. 

Inventing,  on  the  other  hand,  displays  through  the  fashioning  of  an  alternative 
reality.  For  instance,  a  false  file  created  on  a  system  is  still  a  file,  and  it  does  not  mimic  a 
real  file.  The  goal  when  inventing  is  to  create  something  that  has  the  effect  of  being  real 
to  ultimately  conceal  the  real.  Invention  in  computer  systems  can  be  accomplished  with 
scripted  games  where  the  input  from  an  attacker  is  anticipated,  and  the  intended  result  is 
simulated  to  look  real.  In  this  way,  an  alternate  cyber- wo  rid  is  created  that  seems 
interactive,  but  is  actually  only  responding  in  a  predetermined  way. 

Finally,  decoying  can  be  simply  defined  as  deploying  some  unified  type  of 
defense  with  a  variety  of  potential  directions  and  possibilities.  When  a  decoy  is  properly 
implemented,  it  can  hide  the  real  intentions  with  false  options.  In  military  operations, 
decoying  attempts  to  mislead  the  time  or  direction  of  a  particular  attack.  Computer 
systems  can  accomplish  decoying  by  simulating  that  an  attack  is  actually  functioning  as 
intended,  but  without  actual  operating  system  interaction.  Computer  system  decoying 
will  most  effectively  be  accomplished  by  planting  simulation  routines  into  the  software 
that  will  simulate  attacks  when  triggered.  This  type  of  decoying  is  in  contrast  to  the 
Honey  Pot  vision  discussed  in  [20]  in  that  it  is  integrated  into  the  system  through  the  use 
of  intelligent  software  and  preconditions. 
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C.  SOFTWARErBASED  DECEPTION  RESPONSE 

A  “software  decoy,”  as  proposed  by  Michael  and  Riehle  in  [1],  seeks  to  develop 
the  capabilities  of  intelligent  software  modules  to  react  to  malicious  use.  For  a  software 
decoy,  we  propose  that  there  are  three  main  goals  of  a  deception:  correct  identification  of 
malicious  behavior,  isolation  of  the  attacker,  and  believable  simulation  of  the  attack 
effects. 

1.  Correctly  Identify  Attacks 

As  previously  discussed,  accurate  and  timely  detection  of  anomalous  behavior  is 
the  cornerstone  of  the  success  of  the  deception.  Current  intrusion- detection  systems  can 
identify  malicious  use.  Can  they  identify  all  attacks?  Not  yet,  but  many  rules  defining 
“acceptable”  behavior  exist  and  should  be  used.  These  rules  have  well- formed  thresholds 
that  are  set  high  enough  to  allow  for  a  high  degree  of  confidence  in  their  capabilities  to 
correctly  identify  attack  protocols.  With  any  detection  system,  for  example  with 
biometrics,  obtaining  false  positives  and  negatives  are  a  possibility.  A  set  of 
preconditions  should  be  developed  for  software  decoys  that  will  allow  a  high  degree  of 
confidence  in  the  detection  logic. 

2.  Isolate  Attacks 

Simple  decoys  can  extend  a  particular  program;  if  certain  behavior  is  observed, 
the  program  can  behave  in  a  way  other  than  what  is  intended.  In  fact,  the  program  is 
behaving  how  the  programmer  envisioned,  but  the  system  accessibility  of  the  user  is 
being  carefully  controlled  by  the  program  logic.  The  malicious  user  can  be  thought  of  as 
operating  in  a  chamber  that  looks  and  acts  like  the  operating  system  he  expects,  but  is 
actually  an  isolated  part  of  the  program  that  cannot  interact  with  the  actual  system.  How 
an  attacker  can  be  isolated  is  up  to  the  programmer.  For  instance,  the  programmer  could 
offer  a  root- shell  that  looks  and  acts  interactive,  but  is  actually  a  data- collection  box  that 
has  no  ability  to  send  commands  to  the  processor  other  than  “Quit.”  While  the  isolation 
logic  must  be  completely  foolproof,  so  there  is  no  threat  of  unintended  system 
interaction,  it  is,  nonetheless,  essential  to  a  decoy. 
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3.  Believable  Simulation 

The  success  or  failure  of  the  decoy  hinges  on  the  ability  to  deceive  the  attacker. 
There  are  two  main  concepts  to  make  the  simulation  believable  to  keep  the  attacker 
occupied  and  away  from  the  actual  system:  make  the  reactions  predictable  and  make  the 
interaction  real-time. 

a.  Predictable  Reactions 

Thorough  research  into  the  expected  results  of  a  given  attack  must  be 
done.  The  simulated  system  response  should  be  in  line  with  what  the  intruder  is 
intending.  For  example,  when  a  root  kit  is  successfully  installed  on  a  computer  with  a 
Trojan  horse,  the  attacker  will  expect  access  to  the  system  as  a  root  user  with  root 
privileges.  The  deception  should  account  for  this  by  presenting  a  simulated  root  shell 
that  the  attacker  can  use;  otherwise  the  reaction  will  not  be  predictable  and  could  fail.  It 
may  also,  however,  be  interesting  to  an  attacker  to  find  some  confusing  and  unexpected 
results  to  an  attack  attempt.  The  reaction  may  inspire  new  attempts  and  create  new 
protocols  from  which  new  intrusion  detection  signatures  can  be  developed. 

b.  Real-Time  Interaction 

Beyond  protecting  the  operating  system,  the  main  goal  of  a  decoy  is  to 
keep  the  attacker  occupied  and  away  from  the  main  system.  To  keep  the  attacker 
occupied,  the  interaction  should  be  real-time.  If  each  step  of  the  simulation  needs  to  be 
compiled  or  logically  determined,  the  delay  may  cause  the  attacker  to  become 
uninterested  or,  worse  yet,  uncover  the  simulation.  For  instance,  if  the  attacker  tries  to 
cause  a  denial  of  service  by  flooding  the  network,  every  command  that  the  attacker  (and 
other  users,  too)  tries  to  execute  must  be  delayed  accordingly.  This  real-time  interaction 
is  necessary  to  allow  the  deception  to  continue. 
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III.  ATTACKS  AND  RESPONSES 


A.  ATTACK  PROFILE 

For  this  study,  we  narrowed  our  scope  of  possible  computer  exploits  to  a  well- 
known  attack  profile.  We  chose  a  buffer  overflow  exploit  because  of  the  large  amount  of 
documentation  available  on  the  protocol  of  the  attack.  A  buffer  overflow  attack  is  a 
classic  exploitation  in  which  a  malicious  user  sends  a  large  amount  of  data  to  a  server  to 
crash  the  system.  The  system  component  contains  a  buffer  of  fixed  size  in  which  to  store 
this  data.  If  the  amount  of  data  received  is  larger  than  the  buffer,  parts  of  the  data  will 
overflow  onto  the  stack.  If  the  component  does  not  properly  handle  the  resulting 
exception  that  is  raised,  a  security  breach  is  possible.  By  tricking  a  program  into  loading 
machine  code  into  its  memory,  it  is  possible  to  overwrite  the  return  pointer  of  the 
function  [10].  If  this  data  is  code,  the  system  will  then  execute  any  code  that  overflows 
onto  the  stack. 

Buffer  overflow  attacks  exploit  the  lack  of  bounds  checking  on  the  size  of  input 
being  stored  in  a  buffer  array.  By  writing  data  past  the  end  of  an  allocated  array,  the 
attacker  can  make  arbitrary  changes  to  program  state  stored  adjacent  to  the  array.  In 
practice,  the  most  common  buffer  overflow  technique  is  to  exploit  the  weakness  by 
attacking  the  buffers  located  on  the  stack  itself.  Since  the  program  input  comes  from  a 
network  connection,  and  since  file  processing  often  involves  temporary  changes  in  access 
rights,  the  class  of  vulnerability  may  allow  any  user  anywhere  on  the  network  to  become 
a  root  user  on  a  local  host.  This  makes  buffer  overflow  attack  identification  critical  to 
practical  system  security. 

When  the  attacker  is  seeking  to  inject  his  attack  code,  he  provides  an  input  string 
that  is  actually  executable  code.  The  code  is  primarily  binary  machine  code  that  is  native 
to  the  operating  system  being  attacked,  and  it  can  be  simple.  A  common  attack  in  Linux 
systems  produces  a  basic  shell  which  the  attacker  can  then  use  to  enter  the  system.  The 
injected  attack  code  is  a  short  sequence  of  instructions  that  creates  a  shell,  under  the  user- 
ID  of  root.  The  effect  is  to  give  the  attacker  a  shell  with  root  privileges. 

Normally,  the  targeted  program  would  not  execute  malicious  code  that  is  entered 
as  input,  through  a  string.  However,  if  that  input  is  sufficiently  long,  the  buffer  can 
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overflow  because  the  input  to  the  program  is  placed  on  top  of  the  process  stack,  where 
the  computer  is  keeping  track  of  the  program’s  input  and  output  [13].  When  a  program 
function  is  invoked,  a  return  address  to  the  next  code  to  be  executed  is  placed  on  top  of 
the  stack.  The  input  buffer  is  placed  on  top  of  that  address  allowing  for  the  opportunity 
to  write  into  that  space  with  the  input  data.  Using  this  technique,  it  is  possible  to 
overwrite  the  return  address  with  a  malicious  address.  This  allows  the  attacker  to  control 
the  jumping  of  the  function  back  to  the  attack  code  instead  of  the  point  where  the 
function  call  was  made. 

The  process  of  engineering  a  buffer  overflow  attack  is  not  simple,  but  can  be  done 
by  an  attacker  reverse-engineering  the  targeted  program.  This  is  necessary  to  determine 
the  exact  offset  that  the  buffer  needs  to  compute  the  return  address  in  the  stack  frame. 
Sometimes,  to  lessen  the  complexity  of  engineering  an  attack,  an  attacker  estimates  the 
return  address,  then  repeats  the  desired  return  address  several  times  within  the 
approxamate  range  of  the  current  return  address. 

The  description  of  the  attack  techniques  makes  it  sound  as  if  exploitation  through 
construction  of  a  buffer  overflow  were  quite  straightforward.  The  real  work,  however,  is 
finding  a  poorly  protected  buffer  in  which  to  attack.  Many  systems  have  vulnerabilities 
that  lend  themselves  to  this  and  many  other  types  of  attack,  in  fact.  In  1997,  it  was 
reported  that  the  most  common  vulnerabilities  on  the  Internet  were  buffer  overflow  and 
shell  escapes  [13].  A  shell  escape  incorporates  malicious  code  into  the  input  data  for  a 
program  following  an  escape  character  within  a  sequence  of  commands.  In  some  cases, 
when  a  system  encounters  the  escape  character,  it  invokes  a  shell  program  to  interpret 
and  handle  the  code.  Both  of  these  vulnerabilities,  whether  used  separately  or  together, 
result  from  the  inadequate  checking  of  input  data. 


B.  POTENTIAL  ATTACKER  PROFILE 

The  types  of  deceptions  discussed  so  far  are  not  specifically  aimed  at  one  type  of 
attacker.  To  better  defend  against  a  potential  attack,  it  is  important  to  understand  the 
mindset  and  the  intentions  of  a  potential  attacker.  Moreover,  it  is  also  prudent  to 
understand  their  perception  of  reality  and  their  overall  attention  span  to  effectively 
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develop  responses  to  their  malicious  attempts.  Overall,  an  attacker  can  be  characterized, 
as  in  1999  by  the  Federal  Bureau  of  Investigation  [16],  as  a  nerdy,  teen  whiz-kid  who 
may  be  an  antisocial  underachiever,  or  maybe  even  a  social  guru.  Their  style  is  different 
because  they  think  differently,  and  their  intentions  may  vary  from  using  hacking  as  a 
social  and  educational  activity  to  serious  acts  of  fraud,  sabotage  or  espionage.  This  may 
be  attributed  to  the  fact  that  most  are  teenage  males  who  are  proficient  in  C-programming 
language,  has  a  good  knowledge  of  the  TCP/IP  protocol,  and  is  usually  intimately 
familiar  with  UNIX.  All  of  the  attributes  may  indeed  just  be  a  profile  for  a  regular 
teenager,  but  it  is  the  attacker  intentions  that  set  them  apart.  There  are  many  types  of 
attacker,  and  they  are  typically  characterized  by  four  terms:  hacker,  cracker,  phreak,  and 
cyberpunk  [16]. 

1.  Categories  of  Attackers 

First,  a  hacker  is  typically  a  person  who  is  very  computer  intelligent  and  who  often 
enjoys  examining  operating  system  and  application  code  to  discover  how  it  functions. 
This  type  of  attacker  uses  his  or  her  skill  to  penetrate  software  systems  without 
permission  and  tamper  with  the  data  contained  on  them.  The  biggest  threat  from  a  hacker 
is  their  ability  to  implement  espionage  techniques  for  illicit  purposes,  such  as  economical 
gain  or  even  cyber- terrorism. 

A  cracker  is  popularly  characterized  as  a  user  who  circumvents  security  measures 
of  a  system  in  order  to  gain  unauthorized  access.  Their  main  goal  is  to  break  into  a 
system  without  tampering  with  data  or  employing  espionage  techniques.  These  types  of 
attackers  are  likely  to  seek  use  of  the  systems  resources,  possibly  to  launch  a  denial-of- 
service  attack  at  a  later  time.  A  cracker  is  also  capable  of  being  a  governmental  hacker, 
where  the  targets  are  government  computers  and  cyber- terrorism  or  cyber- warfare  is  the 
ultimate  goal. 

A  phreak,  with  the  unusual  spelling,  is  a  person  who  simply  is  trying  to  use  a 
network  illegally,  that  b,  without  paying  for  the  service.  These  attackers  have  been 
observed  as  far  back  as  the  1970s  when  phone  phreaks  would  try  to  gain  access  to  long¬ 
distance  networks  using  their  own  hardware  to  match  the  tones  on  the  phone  line. 
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Phreaks  may  only  be  interested  in  gaining  access  to  elevate  their  own  social  status  or 
acceptance,  similar  to  a  graffiti  artist  [16]. 

Finally,  the  last  category  of  attacker,  a  cyberpunk ,  or  script  kiddie ,  is  a 
combination  of  all  of  the  above  types  of  attacker.  Their  mutation  is  growing  from  the 
proliferation  of  the  Internet,  and  they  may  be  the  most  common  and  dangerous  type  of 
attacker  found  today.  The  cyberpunk  may  have  many  possible  goals  in  mind  from 
gaining  social  acceptance  to  committing  robbery  or  to,  ultimately,  launching  a  cyber¬ 
terrorist  attack  at  a  target,  whether  against  the  government  or  business. 

2.  Attention  Span 

Considering  all  of  the  attributes  of  an  attacker,  what  their  intentions  are,  and  how 
smart  they  really  are,  how  much  time  do  they  actually  spend  trying  to  attack?  This  may 
be  too  broad  of  a  question  for  the  scope  of  this  thesis,  but  we  are  interested  in  studying 
how  an  attacker  perceives  time,  and  how  much  time  he  will  invest  to  attempt  his  attack. 

As  a  an  economist  once  stated,  "What  Information  consumes  is  rather  obvious:  it 
consumes  the  attention  of  its  recipients.  Hence  a  wealth  of  information  creates  a  poverty 
of  attention"  [17].  As  far  as  hacking  is  concerned,  this  suggests  that  the  time  an  attacker 
spends  attempting  access  or  exploiting  a  website  is  proportional  to  his  desire  to  actually 
succeed.  If  he  tries  to  gain  access,  but  is  thwarted  by  a  firewall  for  example,  he  may  give 
up  and  try  to  find  another  victim.  Remember,  most  of  the  time  the  hacker  is  trying  to 
gain  not  only  access,  but  also  peer  recognition  and  popularity. 

As  far  as  a  simple  deception  that  manipulates  time  is  concerned,  then,  how  long  is 
too  long  and  how  long  is  not  long  enough?  Research  gained  from  the  Honeynet  Project 
[18]  shows  that  there  are  advantages  to  speed  for  an  attacker.  The  extent  of  the 
advantage,  though,  is  relative  to  the  time  a  defender  takes  to  detect  and  react  to  the  attack. 
There  is  a  strong  advantage  to  the  attacker  if  he  can  gain  information  about  the  defenses 
of  a  system.  If  he  is  able  to  determine  the  defenses,  by  finding  the  reaction  times 
somehow,  it  is  likely  he  be  able  to  develop  a  strategy  for  overcoming  the  defenses. 
Attackers  will  do  this  by  attacking  and  then  observing  the  reaction  to  the  attack. 
Therefore,  the  deception  needs  to  be  unpredictable  enough  in  the  sense  that  it  cannot  be 
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traced,  but  predictable  enough,  in  terms  of  reaction  times,  to  not  seem  like  a  simulation 
and  seem  believable. 

3.  Attacker  Perception  of  Time 

It  is  commonly  recognized  that  people  perceive  changes  or  events  in  time,  not 
precisely  time  [19].  That  is  to  say,  it  seems  logical  to  perceive  one  event  after  another 
event,  not  the  time  it  takes  to  complete  the  event.  The  duration  of  the  event  is  possibly 
more  complex  to  understand.  However,  what  is  really  being  measured  or  perceived  is  the 
duration  of  the  event  in  the  memory  of  the  perceiver.  It  is  the  memory  of  a  previous 
hack,  or  a  belief  of  how  a  hack  will  work,  that  drives  the  realization  of  the  duration  to  a 
hacker  that  his  attempt  has  been  successful. 

For  the  purposes  of  deception,  an  attacker  perceives  time  on  two  levels.  First, 
when  he  launches  an  attack,  he  estimates,  based  on  a  previous  attempt,  how  long  it  will 
take  to  process  a  request  on  a  given  system.  This  knowledge  may  also  be  based  on  a 
hacker  attempting  small  requests  and  observing  how  long  each  process  takes.  The  second 
level  of  time  perception  is  purely  event-driven.  That  is,  the  attacker  is  only  concerned 
about  what  happens  next  in  the  attack,  similar  to  a  script.  For  this  second  lc\cl,  he  may 
not  be  concerned  with  the  amount  of  time  it  takes  to  process  a  request  or  a  malicious 
request,  but  he  is  only  concerned  with  the  end  result.  For  these  reasons,  it  is  important 
that  the  simple  response  model  be  developed  with  a  firm  grasp  of  processing  time  in 
order  to  implement  the  correct  exaggerated  delay  into  the  simulation. 

C.  DECOY  LEVELS  OF  RESPONSE 

There  are  many  different  kinds  of  computer  security,  but  the  common  thread 
among  all  security  types  is  that  they  are  proportional  to  the  value  of  the  system  they  are 
protecting.  For  example,  computer  systems  that  process  air-traffic  control  need  to  be 
protected  much  more  than  systems  that  processes  flower  orders.  Both  systems  need 
protection,  to  be  sure,  but  the  level  of  protection  is  vastly  different.  The  engineering  of 
the  levels  of  protection,  because  security  is  a  process,  serves  as  a  basis  for  the 
development  of  the  response.  What  degree  of  simulation  or  deception  is  desired  for  the 
system  and  what  the  software  decoy  will  protect  are  important  questions  to  answer,  and 
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the  answer  will  drive  the  development  of  the  deceiving  software.  Three  possible  levels  of 
decoy  response  are  possible,  each  with  its  own  advantages  and  limitations:  a  simple- 
level,  an  intermediate- level,  and  a  complex- level  response  [1]. 

1.  Simple-Level  Response 

A  simple  response  is  a  context-free  response  and  can  often  be  an  exaggeration  of 
system  effects.  Additional  routines  can  be  written  into  software  that  will  react  n  a 
predictable  way  when  a  malicious  user  attempts  to  attack  the  program.  This  could  be  as 
simple  as  inserting  exaggerated  sleep  time,  where  the  user  thread  is  rendered  inactive  for 
a  certain  period  of  time,  into  the  processing  of  a  request  or  it  could  be  deceptive  “games” 
that  entice  the  attacker  to  stay  occupied  in  the  deception.  My  study  included  developing 
a  decoy  that  delays  users  who  are  identified  as  malicious. 

2.  Intermediate -Level  Response 

An  intermediate-  level  response  is  a  step  above  the  simple  response  in  that  it  could 
run  canned  scripts  mimicking  what  the  attacker  would  expect  to  see  when  he  launches  a 
specific  attack.  This  would  require  a  database  of  known  attack  conditions  that  could  be 
evaluated  to  determine  an  attack  is  in  progress.  The  proper  decoy  or  deception  program 
could  then  be  invoked.  The  same  principles  of  isolation  and  exaggeration  would  then 
apply,  but  the  degree  of  difficulty  of  the  deception  could  be  much  more  complex  than  the 
simple- level  response.  For  example,  if  the  attacker  tried  to  run  code  that  enabled  a  root 
shell  to  launch,  the  decoy  could  deploy  a  simulated  shell  and  keep  the  attacker  isolated 
from  the  system.  We  experimented  with  creating  a  root- shell  to  mimic  a  Unix  operating 
system  that  could  be  deployed  during  an  identified  attack,  and  the  results  are  discussed  in 
the  next  chapter. 

3.  Complex-Level  Response 

The  third  level  of  placement  is  the  complex- level.  Decoys  at  this  level  could 
involve  simulation  of  operating  systems  and  networks  with  dynamic  and  distributed 
affects  of  an  attack.  The  principles  of  the  first  two  response  levels  still  apply  here,  that 
the  attack  be  recognized  and  isolated.  A  simulation  could  be  run  from  a  Honeynet-type 
[18]  system  that  can  broadcast  simulated  attack  responses  on  a  broad  scale.  Of  course,  it 
depends  how  important  the  network  is  to  protect  as  to  how  elaborate  the  decoy  should  be. 
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It  may  be  efficient  to  simulate  an  entire  network,  possibly  on  a  CD-ROM.  This  level  of 
decoying  would  provide  many  options  for  an  attacker,  and  may  expose  some  new 
information  that  could  not  be  gathered  when  the  simulation  was  limited  to  simulated 
scripts  and  time  altering.  Decoying  at  this  level  has  been  investigated  in  [23]. 


D.  STRATEGY  OF  A  SIMPLE  RESPONSE 

Sun  Tzu,  in  The  Art  of  War,  also  encourages  his  generals  to  feign  incapacity  when 
capable,  and  to  seem  inactive  when  active  [8].  With  software-based  deception,  these 
concepts  suggest  responses  at  all  of  the  defined  response  levels.  However,  the  incapacity 
must  be  thoroughly  thought  out  logically  before  it  is  implemented.  The  idea  is  to 
anticipate  the  logic  of  the  malicious  user  to  correctly  lead  him  down  our  deceptive  path. 
This  is  attainable  with  thorough  research  into  the  anatomy  of  a  simple  attack.  What  a 
simple  response  is,  how  a  simulation  is  defined,  and  how  a  simple  response  should  be 
developed  are  all  questions  that  need  to  be  answered  to  effectively  develop  a  simple 
response. 

1.  What  is  a  Simple  Deceptive  Response? 

A  simple  deceptive  response  is  an  attempt  to  simulate  the  effects  of  a  malicious 
user  on  a  system,  often  exaggerating  the  intended  results.  It  should  be  implemented  into 
the  software  code,  and  it  should  behave  in  a  predictable  manner.  One  simple  deceptive 
response,  as  previously  discussed,  could  be  a  processing  delay  that  is  implemented  into 
each  request  an  identified  malicious  user  makes.  The  simple  level  of  response  is 
envisioned  as  a  self- protective  measure  embedded  into  software.  If  its  behavior  is 
developed  correctly,  the  response  will  be  believable  and  will  protect  the  system  without 
using  the  system  resources.  In  other  words,  when  an  attack  is  realized,  the  software  logic 
handles  the  malicious  request  by  running  another  portion  of  the  program,  while 
continuing  to  provide  service  to  other  users.  A  simple  response  is  a  reaction  to  a  simple 
attack. 

2.  What  is  a  Simulation? 

Simulation  may  be  the  most  powerful  misdirection  tool  in  computer  system 


design,  especially  when  it  is  combined  with  the  development  of  the  human  interface. 
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Professional  designers  of  computer  systems  create  a  world  where  interactions  happen  in  a 
predictable  and  familiar  way.  Simulation  of  these  interactions  can  be  analogous  to  a 
magic  act.  For  example,  the  mechanical  devices  and  techniques  that  support  a  magic  act 
are  virtually  transparent  to  an  audience  member.  However,  there  are  actually  two 
simultaneous  acts  taking  place  when  a  magician  is  performing:  the  magician’s  reality, 
and  the  audience  members’  reality.  The  magician  perceives  his  own  sleight  of  hand  and 
manipulative  devices.  The  audience,  though,  has  an  entirely  different  view  as  long  as  the 
magician  is  doing  a  competent  job  [14].  This  alternate  reality  is  often  where  the  normal 
and  predictable  laws  are  violated  and  defied.  Human  and  computer  interaction  in  a 
simulation  is  developed  to  make  the  user  believe  that  one  particular  thing  is  happening, 
but  in  fact  something  else  is  taking  place.  A  simulation  is,  in  terms  of  computer 
interaction,  the  careful  altering  of  a  users  reality. 

3.  How  Should  a  Simple  Response  Be  Developed? 

A  simple  deceptive  response  should  be  developed  with  some  limitations 
according  to  a  stated  policy.  For  example,  Sun  Tzu  advises  his  generals  to  pretend  they 
are  inferior  to  encourage  their  enemy’s  arrogance  [8].  This  could  have  adverse 
consequences  because  it  could  charge  the  attacker  with  vigor  to  defeat  the  deception. 
Keeping  this  in  mind,  I  studied  simple  deceptive  responses  using  a  variety  of  ideas. 
Some  responses  are  minor,  some  intentionally  misleading  and  confusing.  The 
employment  strategy,  though,  must  be  clear  with  the  potential  consequences  of  perceived 
inferiority  thoroughly  examined  before  implementation.  Even  with  this  simple  response, 
a  clear  policy  must  be  in  place  to  determine  the  degree  of  simulation  that  is  to  be 
employed. 


20 


IV.  IMPLEMENTATION  OF  A  SIMPLE  DECEPTIVE  RESPONSE 


A.  DEVELOPMENT 

Development  of  the  simple  deceptive  response  incorporated  all  of  the  research  of 
attacker  logic  as  well  as  recognition  of  the  limitation  of  the  extent  of  the  deception. 
While  the  research  is  ongoing,  our  intent  is  to  demonstrate  the  concept  of  a  simple  decoy 
response  for  software-based  deception  with  a  variety  of  logic-based  ideas.  As  a  starting 
point,  I  first  state  the  logic  of  the  test  program  by  defining  normal  and  deception  mode.  I 
then  explore  three  possible  methods  of  implementing  a  simple  deceptive  response  to  a 
malicious  attempt  to  overflow  the  input  buffer  by  examining  timing  delays,  simulated 
logon  screens,  and  simulating  a  root-shell. 

1.  Normal  Mode 

To  develop  a  simple  deceptive  response,  we  began  by  modifying  a  program  that 
was  created  for  support  of  The  MARIE  Project  [21].  The  program  is  a  Java  Servlet  that 
provides  the  user  interface  to  the  MARIE-4  system.  The  basic  operation  of  the  program 
is  that  it  accepts  a  list  of  keywords  from  a  user  via  a  front-end  web  page.  The  web  page 
is  connected  to  a  Jakarta  Tomcat  web  server  [22]  on  a  Unix  operating  system.  The 
keywords  are  parsed  into  words  using  a  StringTokenizer  Java  method  [15].  The  program 
searches  a  database  in  a  locally  stored  file  to  find  rated  caption  candidates  that  match  the 
keywords.  The  matched  pages  are  then  listed  in  decreasing  order  of  rating.  Normal 
mode  is  explicitly  defined  as  a  user  accessing  the  web  page,  entering  a  string  of 
keywords,  and  then  receiving  the  requested  pictures  and  links  through  the  browser-based 
interface.  On  the  top  of  the  next  page  is  Figure  4.1  that  shows  normal  operation  of  the 
program  in  detail. 
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Figure  4. 1  Normal  Mode  Diagram 

2.  Deception  Mode 

To  operate  in  deception  mode,  there  first  needs  to  be  a  trigger  inserted  into  the 
body  of  the  code  to  allow  access  to  the  simulation  once  any  number  of  abstract 
preconditions  are  met.  Once  the  preconditions  are  met,  the  deception  is  triggered,  and  the 
program  is  now  operating  in  deception  mode.  That  is,  the  visual  portion  of  the  program 
looks  real  to  the  user,  but  it  is  actually  responding  differently  in  a  simulated  way.  If  the 
preconditions  are  not  met,  the  program  will  continue  to  operate  in  normal  mode  as 
pictured  in  Figure  4.2. 
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Figure  4.2  Deception  Mode  Diagram 

Note  that  if  deception  mode  is  triggered,  the  operating  system  cannot  be  attacked  because 
the  simulation  will  run  completely  within  the  program.  That  is,  the  simulation  is  being 
run  in  a  virtual  chamber  thereby  protecting  the  operating  system. 

3.  Timing  Delays 

The  development  of  timing  delays  for  deception  was  in  three  phases.  First,  we 
studied  the  strategy  of  the  delays,  then  how  to  develop  abstract  precondition  checks. 
Next,  we  designed  and  implemented  of  the  notion  of  “Sleep.” 
a.  Development  Strategy 

My  experimentation  with  timing  delays  tested  the  idea  of  simulating  an 
increased  load  on  a  computer  system.  We  began  with  the  study  of  a  buffer-overflow 
attack  on  a  web-based  search  engine.  The  goal  was  to  exaggerate  the  delays  caused  by  an 
attempted  denial- of- service  attack.  For  the  deception  to  be  successful,  the  thread 
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(process,  which  could  represent  a  user)  that  is  identified  as  malicious  should  be  the  only 
user  or  thread  to  get  the  exaggeration  of  the  delay.  The  servicing  of  other  users  who  do 
not  meet  the  malicious  criteria  should  continue  uninterrupted.  In  modifying  the  original 
program,  we  tried  to  simulate  the  time  that  the  image- library  server  would  pretend  to  be 
busy  for  an  identified  malicious  user.  The  logic  is  that  the  overflowed  buffer  caused  by 
the  malicious  user  is  bogging  down  the  response  of  the  computer  system.  By  delaying 
the  request  from  the  user,  we  can  simulate  a  successful  launching  of  an  attack. 

Using  the  previous  discussion  of  the  time  perception  of  a  typical  attacker, 
we  reasoned  that  the  delay  should  be  proportional  to  the  average  time  a  program  would 
take  to  run  on  a  targeted  system.  This  time  is  variable  due  to  the  number  of  times  the 
program  has  run  and  the  amount  of  network  traffic  present.  In  practice,  the  first  time  the 
program  was  called  it  took  significantly  longer  to  retrieve  the  pictures  and  links 
compared  to  other  times  it  was  called  from  the  web  link.  Therefore,  the  delay  time  needs 
to  be  proportional  to  the  expected  perceived  time  to  process  the  malicious  requests  after 
the  first  one.  Also,  if  the  keywords  entered  were  vague,  such  as  the  words  “sea”  or 
“ship,”  the  search  took  considerably  longer  to  complete  and  was  aborted  after  five 


minutes.  Figure  4.3  below  shows  the  results  of  a  search  for  some  common  words,  while 
operating  in  normal  mode. 


Times  in  Database 

Show  Results 

Time  to  Search 

Plane 

70792 

918 

3  sec 

Ship 

727291 

Undetermined 

150  sec 

Aircraft  carrier 

2392/  13003 

449 

3  sec 

Destroyer 

37994 

541 

5  sec 

Submarine 

11721 

332 

2  sec 

Helicopter 

1068 

31 

2  sec 

Surface 

9157 

269 

1 

Jet 

1877 

55 

1 

Sunset 

1824 

41 

1 

Sea 

1164373 

Undetermined 

Undetermined 

Blue  Angels 

2226  /  487 

76 

1 

Avg  Time 

2.1  sec 

Figure  4.3  Keyword  Search  Table 
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The  amount  of  search  time  in  Figure  4.3  was  used  to  help  determine  the 
time  the  program  would  need  to  search  for  keywords,  so  that  the  delay  time  could  be 
added  proportionally.  The  results  of  the  delay  are  displayed  in  Figure  4.4. 
b.  Precondition  Checks 

First,  to  identify  a  malicious  user,  we  added  a  number  of  precondition 
checks  to  the  program  to  evaluate  whether  a  user  was  attempting  to  launch  a  buffer- 
overflow  attack.  All  preconditions  were  evaluated  after  the  keyword  string  was  broken 
down  into  words  with  the  StringTokenizer  method  [15]  and  before  the  words  were 
matched  in  the  database.  We  assign  a  weight  factor  to  each  precondition  to  allow  for 
different  degrees  of  suspicion  depending  on  the  likelihood  that  the  attack  is  really  an 
attack  vice  a  typographical  error.  We  started  by  creating  strings  of  known  attack 
beginnings  as  a  comparison  for  the  keyword  strings.  Then,  we  asked  the  following 
questions: 

(1)  Does  the  keyword  string  begin  with  “file//”?  If  the  string 
begins  so,  there  might  be  an  attack  impending  since  the  text  contains  escape  characters. 
But  the  string  could  also  have  been  a  typographical  error,  and  the  user  may  not  be 
attempting  an  attack.  As  a  result,  we  assign  the  likelihood  of  attack  a  value  of  1,  which 
will  still  trigger  the  delay,  but  the  program  will  still  attempt  to  search  for  the  pictures 
after  the  delay. 

(2)  Does  the  keyword  string  begin  with  C-code?  This  check  is  a 
little  more  complex,  but  the  likelihood  of  attack  is  higher  if  it  succeeds.  First,  we 
determine  if  the  keyword  string  begins  with  an  expression  that  resembles  the  beginning 
of  a  C-code  program,  such  as  “#define.”  Then,  we  determine  the  number  of  words,  or 
tokens,  that  are  present  in  the  string.  We  reason  that  if  there  are  many  words,  the 
likelihood  of  a  malicious  program  is  larger  because  a  program  contains  many  tokens  of 
varying  length.  For  this  precondition,  we  choose  twenty  tokens  as  a  starting  point.  If 
there  are  more  than  twenty  words  present  in  the  string  we  assign  a  value  of  ten  to  the 
likelihood  variable.  If  there  are  between  ten  and  twenty  words  there  is  still  a  moderate 
possibility  that  the  string  is  a  program  and  the  likelihood  variable  is  assigned  a  value  of 
two.  Coupled  with  the  first  check  of  “#define,”  we  reason  that  either  length  of  string  is 
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an  indicator  of  a  possible  attack.  There  is  one  difference  in  the  reaction.  A  moderate 
likelihood  of  attack  will  delay  the  user,  then  display  the  results  of  the  search.  A 
probability  assignment  of  ten,  however,  will  delay  the  user  for  a  long  period  of  time  then 
close  the  connection  by  exiting  the  program 

(3)  Does  the  string  begin  with  a  “//”?  Then  we  evaluate  the  length 
of  the  keyword  string.  The  theory  is  that  if  there  is  an  escape  sequence  followed  by  a 
long  string  of  characters,  the  likelihood  is  high  of  a  buffer- overflow  attack  attempt.  A 
minimum  keyword  string  length  of  100  characters  was  chosen  to  be  sure  there  is  an 
attack  underway  if  there  are  that  many  characters  present.  If  the  number  of  characters 
exceeds  100,  we  assign  a  delay  probability  of  ten  and  send  the  user  to  an  unrecoverable 
sleep  sequence  that  will  terminate  the  connection.  The  slash  combination,  however,  may 
in  fact  be  a  typographical  error  not  intended  to  launch  an  attack  if  the  string  is  not  100 
characters  long,  so  we  assign  a  delay  probability  of  one,  then  retrieve  the  pictures  from 
the  repository,  knowing  that  other  logic  in  the  program  will  prevent  a  search  for  non- 
English  code-name  words. 

(4)  Is  there  only  one  long  keyword  entered?  If  that  word  has  a 
length  greater  than  50  characters,  we  reason  that  the  probability  of  attack  is  moderately 
high,  and  assign  a  value  of  seven.  The  program  delays  for  a  long  time,  and  the  server 
will  close  the  connection  before  any  pictures  are  retrieved.  If  the  count  of  words  is  again 
only  one,  but  the  string  is  less  than  50,  the  user  may  have  forgotten  spaces  between  the 
words.  For  this  reason,  we  allow  a  search  without  delaying  knowing  that  the  word  may 
not  be  valid  at  which  time  the  only  result  will  be  an  error  statement  output  to  the  user. 

(5)  Are  there  more  than  ten  keywords?  If  more  than  ten  tokens  are 
entered,  we  reason  that  there  is  a  low  probability  of  attack.  The  delay  factor  in  this  case 
will  be  small  (one),  but  compared  to  the  length  of  delay  for  the  program  to  search  for  the 
pictures  it  is  not  agnificant.  The  reasoning  is  that  if  an  attack  were  attempted,  there 
would  probably  be  other  triggers  present  that  would  be  determined  by  the  previous 
checks. 
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c.  The  Sleep  Method 

Once  the  triggers  were  declared,  the  actual  delay  function  of  the  program 
was  developed.  The  most  straightforward  way  to  delay  is  to  put  a  suspicious  user  thread 
in  a  Java-defined  sleep  mode  for  a  certain  amount  of  time.  The  delay  should  also  have  a 
randomness  about  it  that  could  be  modified  by  the  code  calling  the  method.  And  lastly, 
the  code  should  have  two  modes  of  operation,  one  that  eventually  returns  the  user  to 
normal  mode,  and  one  that  terminates  the  user  thread  without  returning. 

Putting  a  user  thread  to  sleep  is  a  simple,  yet  effective  way  to  delay  the 
user.  The  Java  sleep  method,  when  called  on  a  running  thread,  forces  the  thread  into  a 
non-active,  or  sleeping,  state.  A  sleeping  thread  cannot  use  a  processor  even  if  one  is 
available  [15].  The  sleeping  thread  only  becomes  ready  after  the  designated  sleep  time 
expires. 

The  code  should  be  able  to  randomly  generate  a  sleep  time  based  on  the 
likelihood  the  tagged  thread  is  a  malicious  thread.  One  of  the  principles  of  deception  is 
that  it  should  not  be  predictable.  Randomizing  the  delay  function  is  a  good  way  to  make 
the  delay  unpredictable.  In  our  program,  the  assigned  likelihood  of  attack  is  given  a 
value  from  one  to  ten,  as  discussed  above.  This  value  is  passed  into  the  Sleep  method  as 
an  integer.  If  the  integer  is  not  the  trigger  value  of  86,  the  Sleep  method  generates  a 
random  integer,  between  1000  and  10000  representing  the  initial  milliseconds  the  thread 
will  sleep,  using  the  random  Java  method,  and  multiplies  that  number  by  the  likelihood 
value.  The  thread  is  then  put  to  sleep  for  that  many  milliseconds.  The  range  of  values 
the  user  thread  can  be  put  to  sleep  is  from  1  second  to  100  seconds  to  parallel  the  time  the 
system  would  be  busy  processing  a  malicious  request.  As  displayed  in  Figure  4.3,  the 
average  time  for  processing  keywords  is  2.1  seconds.  To  properly  mimic  this  time,  we 
add  time  to  simulate  network  congestion  and  possible  processing  queues.  Therefore,  the 
minimum  time  for  delay  should  be  approximately  two  seconds,  while  the  maximum  time 
of  100  seconds  will  simulate  a  large  amount  of  processing  time  based  on  the  successful 
launch  of  an  attack. 

If  the  number  passed  into  Sleep  is  a  trigger  value  of  86,  the  method  enters 
what  we  call  the  “deathSleep”  which  puts  the  user  thread  to  sleep  for  1000  seconds  and 
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then  exits  without  actually  performing  the  search.  This  is  for  when  the  likelihood 
variable  has  been  given  a  maximum  value  of  ten,  and  is  intended  to  simulate  a  crash  of 
the  system.  Currently  the  value  of  86  is  assigned  only  when  the  input  keyword  string 
begins  with  “#define”  and  continues  with  an  amount  of  words  greater  than  or  equal  to 
twenty. 

Figure  4.4  displays  the  delaying  aspect  graphically.  The  graph  plots  the 
time  the  program  takes  to  display  the  correct  results  while  incorporating  the  desired 
likelihood  of  attack,  designated  in  Appendix  A  as  the  “weightOf 'Attack .”  The  results 
were  obtained  by  entering  the  same  eleven  keywords  to  trigger  the  delay  while  varying 
the  weightOfAttack  factor.  There  were  three  series  of  data  collected,  each  over  a  span  of 
five  search  attempts.  Series  1  represents  the  time  to  search  with  a  weightOfAttack  value 
of  one  (1),  Series  2  uses  a  value  of  three  (3),  and  Series  3  uses  a  value  of  seven  (7).  The 
search  times  with  the  delay  incorporated  contrast  the  search  times  calculated  in  Figure 
4.3,  showing  the  delay  is  proportional  to  the  likelihood  of  attack. 


Figure  4.4  Time  To  Search  With  Delay  Graph 

4.  Login  Screen 

Simulating  network  access  is  an  interesting  alternative  deception,  and  it  can  be 
used  to  seek  to  confuse  and  entice  an  attacker.  The  appearance  of  a  false  network  login 
screen  may  seem  incredible  and  unexpected  to  a  user,  and  may  further  confuse  and  entice 
him.  We  used  the  simulated  network  login  screen  in  Figure  4.5  instead  of  returning  the 
user  to  the  input  page  without  pictures  after  the  delay.  The  result  is  confusing  to  the  user, 
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and  he  may  choose  to  try  to  gain  access  instead  of  actually  attacking  the  system.  Keep  in 
mind,  the  login  screen  is  simply  another  part  of  the  code  executing,  and  it  has  no  ability 
to  actually  logon  a  user,  but  it  can  appear  to  process  input.  We  experimented  with  a 
range  of  possibilities  for  the  login  screen;  from  allowing  unlimited  attempted  logins  with 
no  delays  to  allowing  a  maximum  of  three  attempts,  with  the  third  triggering  the 
death  Sleep  sequence.  The  program  can  also  write  usernames  and  passwords  to  an 
archive  to  facilitate  future  recognition  of  the  user. 


Figure  4.5  Login  Screen 

5.  Root-Shell  Simulation 

The  ultimate  goal  of  an  attacker  is  to  gain  root  (supervisor)  privileges  on  a 
computer  system.  Buffer- overflow  attacks  are  often  intended  to  produce  root-shells  on 
targeted  and  unprotected  systems,  especially  those  that  are  Unix-based.  We  created  a 
fake  root-shell  screen  that  can  simulate  the  expected  results  (Figure  4.6).  We  have  two 
options:  we  can  display  the  simulated  root- shell  after  any  buffer  overflow  attempt,  or  we 
can  display  it  after  some  number  of  attempted  logins.  The  root- shell  simulation  seems  to 
be  interactive  to  the  user,  but  the  shell  provides,  in  fact,  a  scripted  response  generated  by 
the  software.  Whatever  command  the  user  enters  at  the  cursor,  the  software  follows  with 
a  “ Command  completed  successfully”  message. 
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Figure  4.6  Root  Shell  Simulation 
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V.  DECEPTION  EXPERIMENT 


A.  INTRODUCTION 

To  better  study  the  effectiveness  of  the  concept  of  our  simple  deceptive  response, 
we  devised  an  experiment  to  measure  the  reaction  of  test  subjects.  The  goals  of  the 
experiment  were  to  determine  if  the  subjects  found  the  deception,  whether  the  subjects 
could  perceive  when  they  were  observing  real  or  decoy- simulated  delays. 

1.  Subjects 

The  participants  of  the  study  were  colleagues  and  associates  of  our  group.  They 
were  not  provided  any  incentive  or  preparation  prior  to  their  participation.  The  subjects 
were  separated  into  two  categories:  either  computer  student  or  recreational  user.  The 
subjects  were  not,  though,  potential  attackers.  Two  subjects,  however,  had  some 
experience  with  the  study  of  the  anatomy  of  computer  attacks.  See  Table  5.1. 


Table  5.1  Subjects 


Subject 

Background 

A 

Computer  Student 

B 

Computer  Student 

C 

Recreational  User 

D 

Recreational  User 

E 

Recreational  User 

F 

Computer  Student 

G 

Computer  Student 

H 

Recreational  User 

2.  Program 

The  program  is  a  Java -coded  program  that  is  compiled  and  running  on  off-the- 
shelf  personal  computer  with  a  standard  software  configuration.  The  program  emulates 
all  of  the  capabilities  of  Appendix  A,  while  functioning  without  the  burden  of  a  network 
connection.  The  user  is  able  to  enter  keywords  into  a  search  box,  as  shown  in  Figure  5.1 
on  the  next  page. 
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Figure  5.1  Sample  Input  Screen 

If  the  keyword  input  is  not  an  attack  attempt,  the  program  will  respond  with  a  message  to 
simulate  that  a  search  was  completed,  and  this  indicates  the  program  is  operating  in 
normal  mode,  as  pictured  below  in  Figure  5.2. 


Figure  5.2  Message  Box 

However,  if  the  user  inputs  keyword  data  that  satisfies  one  of  the  trigger 
conditions,  the  Sleep  method  is  called,  and  the  user  thread  is  delayed.  The  capability  is 
also  programmed  into  the  software  to  trigger  the  simulated  login  screen  and  fake  root- 
shell  if  a  known  string  is  entered  into  the  keyword  box. 

3.  Method 

First,  the  subjects  were  asked  two  questions  to  establish  a  baseline  of  their 
perceptions.  Number  one:  How  long  do  they  expect  a  keyword  search  program  would 
take  to  provide  results?  Number  two:  If  they  launched  an  attack,  how  long  would  they 
think  the  system  would  take  to  process  their  malicious  request? 

Second,  the  users  were  individually  placed  in  front  of  the  computer  with  the 
program  pre-comp  iled.  They  were  told  the  keyword  box  would  accept  their  input,  and 
they  were  asked  to  type  in  up  to  five  words  for  the  program  to  search  for.  After  they 
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completed  two  searches,  they  were  told  that  the  mode  they  were  operating  in  was 
considered  “normal.” 

Next,  they  were  told  to  enter  the  string  “file//.”  They  did  not  know  that  the  string 
would  trigger  the  Sleep  method  with  a  weight  Of 'Attack  value  set  to  3.  The  value  of  three 
was  chosen  to  ensure  the  delay  would  not  be  too  short  or  too  long.  They  were  asked  at 
this  point  whether  they  perceived  if  the  search  took  longer  than  the  two  previous 
searches,  with  yes  or  no  being  their  choices. 

For  the  fourth  query,  they  were  asked  to  enter  “#define”  to  trigger  another  delay 
with  a  higher  likelihood  of  attack  of  7,  which  would  delay  for  a  longer  period  of  time. 
They  were  again  asked  at  this  point  whether  they  perceived  that  their  search  took  longer 
than  when  they  were  operating  in  normal  mode,  again  with  yes  or  no  as  choices. 

The  next  two  queries  were  designed  to  test  the  reaction  to  the  presentation  of  the 
simulated  login  screen  and  the  fake  root- shell.  We  inserted  two  keywords  that  would 
trigger  the  simulations:  log  for  the  simulated  login  screen,  and  boss  for  the  fake  root- 
shell.  The  subjects  were  asked  to  enter  one  of  these  words  in  the  search  box,  but  not  told 
what  the  system  reaction  would  be.  The  subjects  were  then  asked  to  give  their  reaction  to 
the  system  response:  surprised,  not  surprised,  expected,  or  no  reaction. 

Finally,  the  subjects  were  asked  to  provide  an  overall  rating  of  the  success  of  the 
deception,  with  the  range  of  values  being  a  1  (poor),  2  ( not  really  believable),  3  (average 
believ ability),  4  (somewhat  believable),  and  5  (completely  believable).  They  were  also 
asked  to  rate  whether  they  were  fooled  or  not,  which  we  presented  three  possibilities: 
fooled,  sort  of  fooled,  and  not  fooled. 


B.  RESULTS 

The  first  two  questions  were  asked  of  the  subjects,  and  the  responses  were  given 
in  seconds.  In  some  cases,  the  subjects  were  allowed  to  generate  approximate  times  for 
their  response,  as  shown  in  Table  5.2. 
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Table  5.2  First  Two  Question  Answers 


Subject 

Search  Time  (sec) 

Attack  time  to  process  (sec) 

A 

Less  than  2 

Approx  30 

B 

Less  than  3 

30-40 

C 

3 

60 

D 

4 

30 

E 

10 

Approx  60 

F 

Less  than  2 

30-40 

G 

Less  than  5 

45  or  less 

H 

3 

Approx  30 

Table  5.3  displays  whether  the  users  perceived  the  delays  during  queries  three  and 

four: 


Table  5.3  Delay  Perception 


Subject 

Perceive  Delay  #1? 

Perceive  Delay  #2? 

A 

Yes 

Yes 

B 

Yes 

Yes 

C 

Yes 

Yes 

D 

Yes 

Yes 

E 

Yes 

Yes 

F 

Yes 

Yes 

G 

Yes 

Yes 

H 

Yes 

Yes 

Table  5.4  now  shows  the  reactions  to  the  fifth  and  sixth  queries,  which  sought  the 
subject’s  reaction  to  the  appearance  of  the  simulated  login  screen  and  the  fake  root- shell. 


Table  5.4  Reaction  to  Queries 


Subject 

Reaction  to  Login 

Reaction  to  Root-Shell 

A 

NOT  Surprised 

Surprised 

B 

Surprised 

Surprised 

C 

Surprised 

Surprised 

D 

NOT  Surprised 

Surprised 

E 

Surprised 

Surprised 

F 

Surprised 

Surprised 

G 

Surprised 

Surprised 

H 

Surprised 

Surprised 
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Finally,  Table  5.5  shows  the  subjects’  comments,  whether  they  were  fooled  or 
not,  and  their  overall  rating  of  the  experiment. 


Table  5.5  Comments  and  Overall  Rating 


Subject 

Comments 

Fooled? 

Overall  Rating 

A 

Believable,  logical 

Fooled 

4 

B 

Very  believable,  effective 

Fooled 

5 

C 

Very  believable,  deceived 

Fooled 

5 

D 

Good  job,  deception  should  work 

Fooled 

5 

E 

Delay  as  expected,  good  graphics 

Fooled 

5 

F 

Believable,  delay  was  what  expected 

Fooled 

4 

G 

Good,  delay  little  long,  surprised 

Sort  of  fooled 

4 

H 

Believable,  good  simulation 

Fooled 

5 

C.  DISCUSSION  OF  RESULTS 

The  results  of  the  experiment  left  the  group  optimistic  about  the  overall  validity  of 
the  simple  deceptive  response  prototype.  The  test  subjects  had  a  wide  range  of  computer- 
related  experience,  but  they  all  reported  being  fooled  by  the  deception,  especially  the 
delaying  tactic.  While  most  subjects  blindly  estimated  the  processing  time  before  the 
execution  of  the  first  search,  the  program  successfully  accounted  for  the  processing  time 
by  proving  valid  an  earlier  discussion  that  the  perception  of  time  is  not  as  concrete  as  the 
perception  of  the  actual  event.  That  is,  the  subjects  perceived  that  it  took  some  amount  of 
time  to  generate  their  intended  reactions  on  the  system.  All  of  the  subjects  had  a 
reasonable  expectation  that  some  event  would  happen  during  the  experiment,  but  they 
seemed  to  have  no  concept  of  the  time  the  program  was  delaying,  only,  in  fact,  that  it 
delayed. 

The  simulated  login  screen  and  the  fake  root- shell  generated  better  than  expected 
reactions.  Most  subjects  felt  the  appearance  of  the  screens  was  surprising  and  believable. 
Only  subjects  A  and  D  were  not  surprised  by  the  appearance  of  the  simulated  login 
screen.  Subject  A  did  expect  network  access  to  become  a  possibility  in  an  attack,  though 
he  stated  he  had  some  knowledge  of  other  types  of  attack  protocols  and  expected  results. 
Subject  D  also  had  limited  knowledge  of  attacks  and  hence  was  not  completely  surprised. 
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The  root-shell  simulation  was  not  expected  by  any  of  the  subjects,  and  successfully 
surprised  all  of  the  subjects.  The  reactions  among  the  computer  students  were  especially 
noteworthy  because  their  subsequent  interaction  with  the  shell  seemed  to  match  their 
expectations  for  “normal”  response  of  the  system  to  their  requests  That  is,  when  they 
typed  in  simulated  commands,  the  “ Command  completed  successfully ”  message  provided 
a  sufficient  level  of  affirmation  that  the  input  was  accepted. 

The  overall  believability  of  the  response  was  very  ligh,  averaging  4.6  out  of  a 
possible  5.0.  The  comments  supported  this  rating,  with  most  subjects  stating  the 
deception  was  either  believable  or,  in  some  cases,  very  believable.  Also,  only  one 
subject,  Subject  G,  stated  he  was  “sort  of  fooled”  by  the  tactics  used,  with  all  of  the  other 
subjects  stating  they  were  for  the  most  part  fooled. 


D.  CONCLUSIONS  OF  EXPERIMENT 

The  experiment,  overall,  provided  better  than  expected  insight  into  the 
believability  of  our  simple  deceptive  response.  The  subjects  were  all  fooled  by  the 
delaying  tactic,  and  fully  surprised  by  the  appearance  of  the  network  login  screen  and  the 
fake  root- shell.  One  of  our  two  goals  was  to  validate  the  believability  of  our  simple 
deceptive  response,  and  that  goal  was  attained  without  question.  The  only  skepticism  we 
noted  was  with  the  more  experienced  subjects  who  thought  the  simulated  screens  were 
too  easy  to  obtain.  However,  these  subjects  expressed  favorable  remarks  at  the  realism  of 
the  display,  especially  when  integrated  with  the  delaying  method.  The  delay  tactic  also 
provided  confirming  evidence  for  the  hypothesis  that  potential  attackers  perceive  the 
events  in  sequence,  not  explicitly  the  time  to  complete  a  process.  The  subjects  were  not 
concerned  with  the  time  it  took  to  process  their  malicious  request;  only  that  it  took  some 
amount  of  time  longer  than  a  request  took  in  normal  (non- decoying)  mode. 

The  second  goal  of  the  experiment  was  to  determine  if  the  subjects  could  tell  they 
were  being  deceived.  Since  they  were  not  told  about  the  delay  function,  all  subjects 
believed  the  computer  was  processing  their  malicious  request,  when  it  was  actually 
delaying.  Coupled  with  the  high  believability  factor,  we  can  conclude  that  the  subjects 
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did  not  realize  that  the  software  application  was  operating  in  deceptive  mode  vice  normal 
mode. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSION 

Our  goal  was  to  evaluate  three  primary  aspects  of  realizing  intelligent  software 
decoys.  First,  we  investigated  how  the  concept  emerged  out  of  the  current  state  of 
intrusion-detection  systems  and  their  limitations.  Since  the  concept  is  maturing,  it  was 
important  to  see  how  the  notion  developed  from  the  current  stagnant  state  of  intrusion- 
detection,  and  the  emerging  cyber-warfare  techniques  that  need  to  be  studied  and 
implemented. 

Second,  as  an  introduction  to  the  concept,  we  expanded  the  definitions  of  the 
three  levels  of  complexity  a  software-based  decoy  response  should  have.  By  defining 
what  a  simple,  intermediate,  or  complex  level  of  response  means,  we  have  laid  the 
foundation  for  future  research.  As  the  need  to  protect  systems  continues  to  evolve,  the 
levels  may  change,  but  their  underlying  organization  should  not  change  substantially. 

Finally,  we  examined  the  technical  feasibility  of  implementing  a  simple- level 
deceptive  response  for  a  software  decoy.  The  simple  model  provided  insight  into  the 
logic,  technical  feasibility,  and  practicality  of  generating  believable  software-based 
deceptive  responses.  It  also  magnified  the  need  for  other  parts  of  the  research  to  fully 
develop,  namely  the  need  to  have  well- formed  abstract  preconditions. 


B.  ACHIEVEMENTS  OF  RESEARCH 

Our  research  into  software-based  deception  fits  between  the  capabilities  of  current 
intrusion-detection  techniques  and  potential  counter- active  techniques,  to  better  equip 
computer  systems  for  the  next  generation  of  cyber- warfare.  Defining  the  levels  of 
response  and  showing  how  they  relate  to  established  military- deception  techniques  forms 
the  basis  for  the  future  development  and  implementation  of  intelligent  software  decoys. 
Also,  by  demonstrating  the  concept  is  applicable  to  modem  computer  systems  through 
the  application  of  a  simple  response  example,  the  research  proved  to  be  logically  relevant 
and  straightforward  to  implement.  The  important  first  step  has  been  taken  to  better 
understand  the  theories  involved  in  software-based  deception. 
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C.  LIMITATIONS  OF  RESEARCH 

One  limitation  of  our  research  was  that  the  proof  of  concept  was  developed  for 
one  type  of  attack:  the  buffer  overflow.  Most  intrusion-detection  techniques  focus  on 
signatures  and  anomaly  detection  and  are  intended  to  be  applicable  to  all  systems.  By 
focusing  on  one  attack  technique  for  this  research,  though,  the  protection  is  not  generic 
and  abstract.  There  are  many  possibilities  of  attack  signatures,  and  this  simple  model 
does  not  cover  all  of  them  abstractly. 

Another  limitation  of  the  research  is  that  the  techniques  it  protects  against  may 
not,  in  fact,  still  be  valid  or  commonly  used.  The  preconditions  protect  against  one  kind 
of  attack.  The  decoying  methods,  though,  can  be  reused  for  other  variations  of  buffer- 
overflow  attacks. 


D.  RECOMMENDATIONS  FOR  FUTURE  RESEARCH 

Since  the  technology  and  concept  of  intelligent  software  decoys  is  still  in  the 
developmental  stage,  there  exist  many  avenues  for  research.  Three  particular  areas  are 
the  following:  development  of  the  intermediate  and  complex  levels  of  response,  the 
concept  of  isolation,  and  the  integration  of  the  dynamic  wrapping  technology. 

The  advanced  levels  of  response  --  intermediate  and  complex  --  should  be  studied 
and  attempts  should  be  made  to  develop  proof- of- concept  prototypes.  As  the  simple 
response  was  developed,  the  idea  of  running  canned  scripts  emerged  as  a  way  to 
implement  the  simulation.  With  intermediate- level  responses,  the  simulation  can 
continue  to  grow  and  protect,  culminating  with  the  complex- level  response  that  should 
incorporate  the  supervisor  concept  [24]  and  the  dynamic  wrapping  technology. 

Second,  isolating  the  attacker  from  the  system  is  one  of  the  main  goals  of  the 
decoy.  If  there  is  any  possible  way  to  interact  with  the  computer  system  directly  from  the 
simulation,  the  possibility  will  exist  for  further  exploitation,  and  the  results  may  be 
disastrous.  Much  the  same  way  as  the  simulation  needs  to  be  a  closely  guarded  secret, 
the  interaction  between  a  malicious  user  and  a  computer  system  must  be  strictly 
controlled  at  all  times.  The  concept  of  a  virtual,  “escape-proof’  chamber  that  the 
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simulation  will  run  in,  away  from  the  actual  operating  system,  should  be  studied  and 
implemented.  Michael  and  Riehle  have  termed  this  an  antechamber  [1], 

Lastly,  the  dynamic  wrapping  technology  that  is  being  studied  should  be 
integrated  with  the  response  models.  The  technology  involves  developing  an  abstract 
language  to  evaluate  behavior  of  a  user  within  a  system,  and  that  technology  could  be 
used  to  protect  against  a  large  number  of,  if  not  all,  attacks.  The  dynamic  deployment 
capability  to  lcspond  is  an  exciting  possibility  that  could  prove  to  be  the  best  way  to 
simulate  responses. 
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APPENDIX  A 


KEYWORD  SEARCH  PROGRAM  WITH  DECEPTION 


package  dpjulian; 

//********************************************************************/ 


//  Servlet  for  user  interface  to  the  MARIE-4  system.  / 
//  Accepts  list  of  keywords  from  the  user,  searches  a  database  of  / 
//  rated  caption  candidates  from  RateCaps.out  to  find  matches,  / 
//  lists  their  pages  in  decreasing  order  of  rating;  user  can  click  on  / 
//  them  to  go  to  those  pages.  Modified  with  preconditions  for  input  / 
//  of  search  string  keywords.  Used  as  test  to  identify  intrusions  / 
//  and  run  simulated  reactions  to  intrusion.  Modified  for  Masters  / 
//  Thesis  Naval  Postgraduate  School  Summer  2002.  / 
//  Author(s) :  Donald  P.  Julian  and  Neil  C.  Rowe  / 


//********************************************************************/ 

import  java. util.*; 

import  java.io.*; 

import  java. text.*; 

import  java.awt.*; 

import  j ava . awt . event .* ; 

import  java.net.*; 

import  java.lang.*; 

import  j avax . servlet .* ; 

import  javax . servlet . http .* ; 

import  j avax . swing .* ; 

public  class  JulianSearchver2  extends  HttpServlet  { 

/*  To  hold  known  destemmed  words  of  English  */ 

HashSet  rchs  =  new  HashSetO; 

/*  To  hold  pointers  to  capindex.out  for  a  word  */ 

String  Indexwords  []  =  new  String [ 500000 ] ; 
long  Indexaddresses [ ]  =  new  long [ 500000 ] ; 

/*  To  store  web-page,  caption,  and  image-file  index  numbers  for 
words  */ 

String  Word,  Inputline; 
int  Indexlength; 
int  weightOf Attack; 
int  tryChecker  =  0; 

HashMap  abbrevs  =  new  HashMap (4000) ; 

//  Initialize  the  servlet  by  loading  main  data  structures 
public  void  init  ()  { 

System . out . print in (" Start ing  init  routine"); 

int  k,  kl,  k2 ,  j,  jl,  j2,  j3,  j4,  j5,  jend; 

long  startindex; 

String  Weightstring,  sourcestring,  captionstring,  imagestring, 

SLoc, 

Abbrevline,  Abbrev,  Expan; 

//  Load  dictionary  for  the  destemmer 

try  {  rowe . Destemmer . hashKnownWords (rchs ); } 

catch  (IOException  e)  { System . out . print in (" 10  Error");} 

//  Load  index  on  words  that  gives  caption-pictureref  pairs 
k2  =  0; 

try  {  FileReader  fr  = 

new  FileReader ( " / work/ rowe /my java/ navy . cap index index . out " )  ; 
Buf feredReader  br  =  new  Buf feredReader (f r) ; 
startindex  =  0; 
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while  ((Inputline  =  br . readLine ( ) )  !=  null)  { 

//  Store  for  each  destemmed  word  a  byte  address  in  index. out, 

//  in  alphabetical  word  order, 
j  =  Inputline . indexOf  (  '  '); 

Word  =  Inputline . substring (0, j ) ; 

SLoc  =  Inputline . substring ( j  +  1, Inputline . length ())  ; 
startindex  =  Long . valueOf ( SLoc)  . longValue ()  ; 

Indexwords [ k2 ]  =  Word; 

Indexaddresses [k2]  =  startindex; 
k2++ ;  } 

f r . close  ( )  ; 

FileReader  fr3  =  new  FileReader (" /work/rowe/my java/abbrevs . txt ") ; 
Buf feredReader  br3  =  new  BufferedReader (fr3)  ; 
while  ( (Abbrevline  =  br3 . readLine ()  )  !=  null)  { 

kl  =  Abbrevline . indexOf (  '  '); 

Abbrev  =  Abbrevline . substring (0,  kl)  ; 

Expan  =  Abbrevline . substring (kl  +  1 ,  Abbrevline . length ())  ; 
abbrevs . put (Abbrev,  Expan)  ;  } 

f r3 . close  ( ) ; 

FileReader  fr4  =  new  FileReader (" /work/rowe/my java/synonyms . txt ") ; 
BufferedReader  br4  =  new  Buf feredReader (fr4 ) ; 
while  ((Abbrevline  =  br4 . readLine () )  !=  null)  { 

kl  =  Abbrevline . indexOf ( '  '); 

Abbrev  =  Abbrevline . substring (0,  kl)  ; 

Expan  =  Abbrevline . substring (kl  +  1 ,  Abbrevline . length ())  ; 
abbrevs . put (Abbrev, Expan) ;  } 

f r4 . close  ( ) ;  } 

catch  (IOException  e)  {  System . out . print In  (  "File  Error");} 
Indexlength  =  k2; 

System . out . print In ( "navy . capindexindex . out  loaded.");  } 

/*  Respond  to  a  front-end  request  to  find  Web  images  whose  captions 
match  at  least  one  of  a  given  list  of  keywords.  */ 
public  void  doGet (HttpServletRequest  request,  HttpServletResponse 
response ) 

throws  ServletException,  IOException  { 

/*  To  hold  extracted  set  of  keywords  from  user  request,  plus  */ 

/*  index  address  of  start  of  record  and  length  of  the  record.  */ 

String  KeywordArray  []  =  new  String  [100]; 

long  KeywordAddresses  []  =  new  long  [100]; 

long  KeywordBytes  []  =  new  long  [100]; 

long  BytesSorter  []  =  new  long  [100]; 

int  TreeMapMax  =  10000; 

/*  To  hold  extracted  set  of  relevant  Web  pages  and  their  captions 

*/ 

String  stringresults  []  =  new  String  [TreeMapMax]; 

/*  To  hold  the  weights  for  each  caption  result  */ 
double  Resultweights  []  =  new  double  [TreeMapMax]; 

/*  To  hold  the  index  numbers  for  each  caption  result  */ 
long  Resultnumbers  []  []  =  new  long  [TreeMapMax] [3]; 

/*  To  hold  the  URLs  of  image  files  */ 

String  Imagefiles  []  =  new  String  [TreeMapMax]; 

/*  To  flag  the  caption  results  once  shown  */ 
boolean  Shownresults  []  =  new  boolean  [TreeMapMax]; 

String  keywordstring,  wantpicsstring.  Word,  WordData,  Page, 
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SWeight,  Sresultscount ,  resultline,  CaptionNumbers,  Webpage, 
CaptionNumberString,  maxcaptioncountstring.  Webpagestring, 
Captionstring,  Caption,  Imagelink,  Pagecapstring,  Lastlmagelink, 
Imagestring,  datastring.  Weightstring,  tmpword; 
double  Weightl,  NewWeight,  Weight,  Weightmax,  Weighttotal, 

Weight Threshold; 

Double  DOldWeight,  DWeight; 

int  Capnum,  maxcaptioncount,  showableresultscount, 
shownre suits count , 

k,  kO,  kl,  k2,  k3,  M,  Wordindex,  j,  j2,  j5,  jend, 

extraresultscount,  i,  i2,  ilo,  ihi,  imed,  lastimed,  cmp, 
Keywordcount ,  Capsfound; 

Integer  IWordindex; 

long  startindex,  Pagenumber,  Captionnumber,  Imagenumber, 

Webpageptr , 

tmpaddr,  tmpbytes,  recordlength; 

Long  Lstartindex; 

boolean  matchflag,  indexflag; 

char  c; 

Collator  MyCollator  =  Collator . getlnstance  () ; 

/*  Set  up  servlet  response  */ 
response . set Content Type ( "text/html " ) ; 

PrintWriter  pw  =  response . getWriter ()  ; 

System . out . print in ( " Start ing  doGet " )  ; 

/*  Extract  the  inputs  from  the  front  Web  end  page,  SearchCaps.html 

*  / 

keywordstring  =  request .getParameter ("keywords") ; 
wantpicsstring  =  request . getParameter ( "wantpics" ) ; 
boolean  wantpics  =  false; 

if  (wantpicsstring . equals ( "pics ") )  {wantpics  =  true;} 
maxcaptioncountstring  =  request . getParameter ( "maxcaptioncount  "  )  ; 
maxcaptioncount  = 

Integer . valueOf (maxcaptioncount string) . intValue ( ) ; 

//  HttpSession  session  =  request . getSession  (true) ; 

/*  Use  only  three  decimal  digits  of  accuracy  in  calculation  */ 
DecimalFormat  DF  =  new  DecimalFormat ( ) ; 

DF . setMaximumFractionDigits (3)  ; 

DF . setMinimumFractionDigits (3)  ; 

/*  Open  random-access  index  file  */ 

File  af  =  new  File (" /work/rowe/my java/navy . capindex . out ")  ; 
RandomAccessFile  raf  =  new  RandomAccessFile (af , " r " ) ; 

/*  Use  tree  to  hold  weights  of  each  relevant  Web  page  found  */ 
TreeMap  tm  =  new  TreeMap ( ) ; 
int  KeywordCount  =  0; 
int  resultscount  =  0; 

Weighttotal  =  0.0; 

Weightmax  =  -1000.0; 

//  Analyze  the  keywords  and  find  pointers  to  those  in  the  index; 

//  sort  by  increasing  size  of  the  index  record  (most  specific 
first ) 

StringTokenizer  st  =  new  StringTokenizer (keywordstring,  "  ,  ;\t"); 
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/*******************************************************************/ 
/*****************BEGIN  PRECONDITION  check*  *************************/ 
/*******************************************************************/ 

/* 

Here  is  a  series  of  pre-conditions  that  need  to  be  evaluated  before  the 
program  locates  the  pictures  in  the  database. 

*/ 

//  Local  variables. 

String  buffOverl  =  "file//"; 

String  cStart  =  "#define"; 

String  slash  =  "//"; 


/* 

Evaluating  if  the  keywordstring,  the  input  from  the  web  page,  here.  If 
the  string  begins  with  'file//',  I  assume  an  attack  attempt  and  delay 
but  still  return  to  find  the  pictures  in  the  database. 

*/ 

if  (  keywordstring . startsWith (  buffOverl  )  ){ 

//  GO  TO  DELAY  THEN  GO  TO  SEARCH  -  LOWER  PROBABILITY  OF  ATTACK 
//  BUT  DELAY  THEN  GET  PICS 

System. out .println (  "\nAttack  recognized,  going  to  sleepXl."  ); 
weightOf Attack  =  1; 

Sleep  sim  =  new  Sleep (  weightOf Attack  ); 

} 

/* 

Here,  the  check  if  for  a  beginning  word  of  '#define'.  If  the  string 
begins  that  way,  then  I  assume  the  attacker  is  trying  to  launch  code 
through  the  browser.  If  the  number  of  words  is  between  1  and  20,  then 

I  assume  it  may  be  an  attack,  but  it  could  be  a  typo  so  I  delay,  then 

search  for  pictures.  If  the  length  of  the  string  is  >=  20  words,  then 
the  probability  of  an  attack  is  higher,  when  coupled  with  the  string 

'tdefine'.  The  value  of  20  words  is  the  chosen  threshold  of  whether 

there  is  following  C  code  present  or  not. 

*/ 

if  (  keywordstring . startsWith (  cStart  )  ){ 

if  (  st . countTokens  ( )  >=  1  &&  st . countTokens  ( )  <  20  )  { 

System. out .println (  "\nAttack  recognized,  going  to  sleep."  ); 
weightOf Attack  =  2; 

Sleep  sim  =  new  Sleep (  weightOf Attack  ); 

} 

else  if  (  st . countTokens ( )  >=20  ){ 

System. out .println (  "\nAttack  recognized,  going  to  DEATH 
sleep . "  ) ; 

weightOf Attack  =  10; 

Sleep  sim  =  new  Sleep (  86  );  //Change  when  LogonScreen  ok. 

/*  LogonScreen  logon  =  new  LogonScreen () ;  */ 


/*  Evaluating  if  there  are  25  or  more  keywords  to  search  for.  If  there 
are, I  assume  there  is  a  higher  likelihood  of  attack,  a  of  value  7. 

Goes  to  LogonScreen  routine,  which  it  cannot  recover  from. 

*/ 
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if  (  st.countTokens  ()  >=25  ){ 

//GO  TO  DELAY,  THEN  GO  TO  LOGON  SCREEN  ->  DOES  NOT  GET  PICS 

System. out .println (  "\nAttack  recognized,  going  to  sleepX7."  ); 
weightOf Attack  =  7; 

Sleep  sim  =  new  Sleep (  weightOf Attack  ); 

LogonScreen  logon  =  new  LogonScreen ( ) ; 


/* 

Here,  the  evaluation  is  whether  the  keywordstring  input  starts  with  an 
expression  resembling  a  C-code  program,  such  as  a  /,  and  whether  the 
length  is  greater  than  100  characters.  If  it  is,  then  there  is  a  very 
high  likelihood  of  attack.  I  delay  for  a  long  time  then  proceed  to  the 
logon  screen  routine  to  end  the  program. 

*  / 

if  (  keywordstring . startsWith (  slash  )  ){ 

if  (  keywordstring . length ( )  >=  100  ){ 

//  HERE,  THERE  IS  A  VERY  GOOD  POSSIBILITY  OF  AN  ATTACK,  SO  THE 
//  DELAY  SHOULD  BE  HIGH,  THEN  GO  TO  LOGON  SCREEN 

System. out .println (  "\nAttack  recognized,  going  to 
DEATHS leep . "  ); 
weightOf Attack  =  10; 

Sleep  sim  =  new  Sleep  (  86  );  //Change  when  LogonScreen  ok 
/*  LogonScreen  logon  =  new  LogonScreen  () ;  */ 

} 

else{  //The  slash  may  be  a  typo,  so  delaying  a  little  here 

System. out .println (  "\nAttack  recognized,  going  to  sleepXl." 

) ; 

weightOf Attack  =  1; 

Sleep  sim  =  new  Sleep (  weightOf Attack  ); 


/* 

Here,  if  the  is  only  one  word  entered,  and  it  has  a  length  of  greater 
than  50  characters,  then  there  is  again  a  high  probability  of  attack. 

I  delay,  then  proceed  to  the  logon  screen  routine. 

*/ 

if  (  st.countTokens  ()  ==  1  )  { 

if  (  keywordstring . length ( )  >=50  ){ 

System. out .println (  "\nAttack  recognized,  going  to  sleepX7." 

) ; 

weightOf Attack  =  7; 

Sleep  sim  =  new  Sleep (  weightOf Attack  ); 

LogonScreen  logon  =  new  LogonScreen ()  ; 


/* 

If  more  than  10  words  entered,  calling  Sleep  to  delay.  Sends  1  as 
weight  of  attack  for  a  low  probability.  Delays,  then  continues  with 
finding  pictures. 

*/ 
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if (  st . countTokens  ( )  >=10  ){ 

System. out .println  (  "\nAttack  recognized,  going  to  sleep."  ); 
weightOf Attack  =  1; 

Sleep  sim  =  new  Sleep (  weightOf Attack  ); 

} 

if  (  keywordstring . startsWith (  "Rowe"  )  ){  //TEST  -  REMOVE  LATER 

LogonScreen  Is  =  new  LogonScreen ( ) ; 

} 

/********************************************************************/ 
/*********  *EnD  OF  P  RE  COND I T I ONS  *************************************  / 
/*******************************************************************/ 


/* 

/  Now,  continuing  with  the  search  if  not  in  LogonScreen. 

*/ 

KeywordCount  =  0; 

while  (st.hasMoreTokens () )  { 

Word  =  ( st . nextToken ( )  )  . toLowerCase ( ) ; 
if  ( (Word . length ( ) >1 )  &  &  ( !  (number St ring (Word) ) ) )  { 

if  (abbrevs . containsKey (Word)  ) 

Word  =  (  (String) abbrevs . get (Word) ). toLowerCase ()  ; 
else  Word  =  rowe . Destemmer . destem (Word,  rchs )  ; 

//  Do  binary  lookup  in  main-memory  index  to  find  address 
//  on  disk  of  the  record  for  this  word 
ilo  =  0; 

ihi  =  Indexlength; 
indexflag  =  true; 
lastimed  =  -1; 
while  (indexflag)  { 

imed  =  (ilo  +  ihi)  /  2; 

//  System . out . print In (" imed :  "  +  imed  +  "  word:  "  + 
Indexwords [imed] )  ; 

cmp  =  MyCollator . compare (Word, Indexwords [ imed] ) ; 
if  (cmp  ==  0)  { 

KeywordArray [KeywordCount ]  =  Word; 

KeywordAddresses [KeywordCount ]  =  Indexaddresses [ imed] ; 
KeywordBytes [KeywordCount ]  = 

Indexaddresses [ imed+1 ]  -  Indexaddresses [ imed]  ; 
BytesSorter [KeywordCount ]  =  KeywordBytes [KeywordCount ] ; 
KeywordCount++ ; 

indexflag  =  false;  } 


else  if  (cmp<0)  ihi  =  imed; 
else  ilo  =  imed; 

if  (imed  ==  lastimed)  indexflag  =  false; 
lastimed  =  imed;  }  }  } 

//  Interchange  pairs  of  entries  to  sort  keywords  by  record  length 
Arrays . sort (BytesSorter, 0, KeywordCount) ; 
for  (i=0;  i< (KeywordCount-1 ) ;  i++) 

if  (KeywordBytes [ i ]  !=  BytesSorter [ i ] ) 

for  (i2=(i+l);  i2<KeywordCount ;  i2++) 

if  (KeywordBytes [ i2 ]  ==  BytesSorter  [  i ] )  { 

tmpword  =  KeywordArray [ i ] ; 
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tmpaddr  =  KeywordAddresses [ i ] ; 
tmpbytes  =  KeywordBytes [ i ] ; 

KeywordArray [ i ]  =  KeywordArray [ i2 ] ; 

KeywordAddresses [ i ]  =  KeywordAddresses [ i2 ] ; 

KeywordBytes [ i ]  =  KeywordBytes [ i2 ] ; 

KeywordArray [ i2 ]  =  tmpword; 

KeywordAddresses [ i2 ]  =  tmpaddr; 

KeywordBytes [ i2 ]  =  tmpbytes;  } 

System . out . print In ( "KeywordCount :  "  +  KeywordCount ) ; 
for  (i=0;  i<KeywordCount ;  i++) 

System . out . print In (KeywordArray [ i ]  +  "  "  +  KeywordAddresses [ i ]  + 

II  II  i 

KeywordBytes [ i ]  +  "  "); 

//  Store  pointers  for  each  keyword  into  a  tree 
System . out . print in (" Start ing  loop  on  keywords"); 

Capsfound  =  0; 

for  (i=0;  i<KeywordCount ;  i++)  { 

Word  =  KeywordArray  [  i ] ; 

System . out . print in ( "Working  on  word  +  Word  + 
startindex  =  KeywordAddresses [ i ]  ; 
recordlength  =  KeywordBytes [ i ] ; 

//  Extract  the  index  data  from  the  capindex.out  record 
raf . seek (startindex)  ; 

while  ((c  =  (char ) raf . read () )  !=  'I')  {}; 

c  =  (char ) raf . read () ; 
while  (c  ==  '  '  )  { 

Weightstring  = 

while  ( (c  =  (char ) raf . read () )  !=  '  ') 

Weightstring  =  Weightstring  +  c; 

Pagecapstring  = 

while  ( ( c  =  (char ) raf . read () )  !=  'I') 

Pagecapstring  =  Pagecapstring  +  c; 

Pagecapstring  =  Pagecapstring . substring ( 0 , Pagecapstring . length ( ) - 

1)  ; 

Weightl  =  Double . valueOf (Weightstring) . doubleValue () ; 

/*  Adjust  using  inverse  keyword  document  frequency.  */ 

Weightl  =  0 . 1 *Weight 1 *Math . log ( 50000 . 0/ (recordlength*0 . 03 ))  ; 
Weighttotal  =  Weighttotal  +  Weightl; 

//  Store  weight  found  for  matched  caption  in  tree 
if  (! (tm. containsKey (Pagecapstring) ) )  { 

/*  System . out . print in ( "New  page  "  +  Pagecapstring  + 

"  at  weight  "  +  Weightl) ;  */ 
if  (Capsfound  <  TreeMapMax)  { 
re suits count ++; 

if  (Weightl  >  Weightmax)  Weightmax  =  Weightl; 
tm. put (Pagecapstring,  new  Double  (Weight  1 )) ;  }  } 

else  { 

/*  Add  the  weights  for  each  keyword  mentioned  in  the  caption  */ 
DOldWeight  =  (Double)  tm. get (Pagecapstring) ; 

NewWeight  =  DOldWeight . doubleValue ( )  +  Weightl; 

/*  System . out . print in ( "Page  "  +  Pagecapstring  + 

"  changed  weight  to  "  +  NewWeight) ;  */ 
if  (NewWeight  >  Weightmax)  Weightmax  =  NewWeight; 
tm. put (Pagecapstring,  new  Double (NewWeight )) ;  } 
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Capsf ound++; 

c  =  (char ) raf . read () ;  }  } 

raf . close ( ) ; 

/*  Now  collect  all  the  pages  and  fill  array  stringresults  with 
strings 

containing  their  weight  and  their  link.  */ 

/*  Set  weight  threshold  to  reduce  chance  of  >  500  answers.  */ 
double  Weightaverage  =  Weighttotal/ (double) resultscount ; 
if  (resultscount  >  1000)  WeightThreshold  =  Weightaverage; 
else  WeightThreshold  =  0.0; 

/*  Build  second  tree  to  sort  the  Web-page  results  found  */ 

TreeMap  tm2  =  new  TreeMap ( )  ; 

Set  set  =  tm. entrySet ( ) ; 

Iterator  iter  =  set . iterator () ; 
int  oldresultscount  =  resultscount; 
resultscount  =  0; 
while  (iter . hasNext ( ) )  { 

Map. Entry  me  =  (Map . Entry ) iter . next () ; 

DWeight  =  (Double ) me . getValue () ; 

Weight  =  DWeight . doubleValue ()  ; 
if  (Weight  >  WeightThreshold)  { 

while  (tm2 . containsKey (DWeight )  )  { 

Weight  =  Weight-0.0001; 

DWeight  =  new  Double (Weight ) ;  } 

tm2 . put (DWeight ,  me . getKey ( ) ) ; 
resultscount++;  }  } 

pw . print In ( " <HTML>\n<BODY>\n" ) ; 
if  (resultscount  >  0)  { 

//  Generate  header  for  the  returned  dynamic  Web  page 

pw . print In (" <H2>Images  matching  keywords  &quot;"  +  keywordstring 

+ 

"&quot;,  in  order  of  decreasing  likelihood.  ("  + 
oldresultscount  + 

"  captions  matched  at  least  one  keyword.  )  </H2xbr>")  ; 
/*  Determine  the  actual  image  file  URLs  and  store  in  array  */ 
File  afi  =  new  File (" /work/rowe/my java/navy . capimage . out ") ; 
RandomAccessFile  rafi  =  new  RandomAccessFile (af i , " r " ) ; 

//  Find  the  best  captions  matching  the  keywords 
showableresultscount  =  Math . min (resultscount ,  TreeMapMax)  ; 

System . out . print In (" showableresult scount :  "  + 
showableresultscount) ; 

for  (k=0;  k<showableresultscount ;  k++)  { 

DWeight  =  (Double )  (tm2 . lastKey ())  ; 

Weight  =  DWeight . doubleValue () ; 
resultline  =  ( St ring) tm2 . get (DWeight ) ; 
tm2 . remove (DWeight)  ; 
k2  =  resultline . indexOf ( '  '); 

k3  =  resultline . indexOf ( '  ',k2+2); 

M  =  resultline . length ()  ; 

Webpagestring  =  resultline . substring (0, k2) ; 

Captionstring  =  resultline . substring (k2+l , k3 ) ; 

Imagestring  =  resultline . substring (k3+l , M) ; 

Pagenumber  =  Long . valueOf (Webpagestring) . longValue () ; 
Captionnumber  =  Long . valueOf (Captionstring) . longValue () ; 
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Imagenumber  =  Long . valueOf ( Imagestring) . longValue () ; 

Resultweights [k]  =  Weight; 

Resultnumbers [k] [0]  =  Pagenumber; 

Resultnumbers [k] [1]  =  Captionnumber; 

Resultnumbers [k] [2]  =  Imagenumber; 

Shownresults [k]  =  false; 

rafi . seek (Resultnumbers [k] [2] ) ; 

Imagef iles [k]  =  raf i . readLine ( ) ;  } 

rafi . close  ( ) ; 

/*  Open  for  random  access  the  Web-page  and  caption  files  */ 

File  afs  =  new  File (" /work/rowe/my java/navy . capsource . out ") ; 
RandomAccessFile  rafs  =  new  RandomAccessFile (afs, "r" ) ; 

File  afc  =  new  File  (" /work/rowe/my java/navy . capcapt ion . out ")  ; 
RandomAccessFile  rafc  =  new  RandomAccessFile (afc,  " r" )  ; 

//  Generate  HTML  for  the  best  captions 
shownresultscount  =  0; 
for  (k=0;  ( (k<showableresultscount )  & 

(shownresultscount<maxcaptioncount) )  ;  k++)  { 

if  (!  Shownresults [k] )  { 

shownre suits count ++ ; 

Imagelink  =  Imagef iles [k] ; 

Webpageptr  =  Resultnumbers [k] [0]; 
rafs . seek (Resultnumbers [k] [0] ) ; 

Webpage  =  raf s . readLine () ; 
rafc. seek (Resultnumbers [k] [ 1 ] ) ; 

Caption  =  raf c . readLine () ; 

/*  If  user  wants  pictures,  insert  Web  image  reference  */ 
if  (wantpics)  { 

pw . print in (" <img  src='"  +  Imagelink  + 

"  '  \n  alt='"  +  Caption  +  '"><br>\n"); 

/*  List  the  Web  page  the  above  picture  came  from  */ 

pw . print in (" The  above  picture  is  from  <A  HREF  =  '"  +  Webpage 

+ 

+  Webpage  +  "</A><br>\n"  );  } 

else  { 

/*  Else  list  the  Web  page  matching  the  keywords  */ 
pw . print in (" Try :  <A  HREF  =  '"  +  Webpage  + 

+  Webpage  +  "</A><br>\n"  );  } 

extraresultscount  =  Math . min ( showableresult scount , 
l+k+ ( ( (maxcaptioncount- 

shownresultscount ) * (k+1) ) /shownresultscount)  ) ; 

/*  System . out . print in (" shownresult scount :  "  + 
shownresultscount  + 

"  extraresultscount:  "  +  extraresultscount);  */ 

/*  List  the  caption  and  any  other  captions  on  the  same  image  */ 
for  (k2=k;  k2<extraresultscount ;  k2++)  { 

if  ((! Shownresults [k2] )  & 

(Imagefiles [k2] .equals (Imagelink) ) )  { 

if  ( !  (Webpageptr  ==  Resultnumbers [k2]  [0]  )  )  { 

Webpageptr  =  Resultnumbers [ k2 ] [0]; 
rafs . seek (Resultnumbers [k2]  [0] ) ; 

Webpage  =  raf s . readLine () ; 
pw . print in (" The  picture  also  appears  on  <A  HREF  = 

+ 

Webpage  +  +  Webpage  +  "</Axbr>\n"  );  } 
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rafc.seek (Re suit numbers [ k2 ]  [  1 ] ) ; 

Caption  =  raf c . readLine ( ) ; 

Weight  =  Resultweights [k2] ; 

pw . print in (" <b>Capt ion  of  weight  "  +  DF . format (Weight )  + 

</b>&quot  "  +  Caption  +  " &quot<br>\n" ) ; 

Shownresults [k2]  =  true;  }  }  }  } 

raf s . close  ( ) ; 
raf c . close ( ) ;  } 

else  { 

pw . print in (" <h3>No  images  matching  any  keywords  were 
found. </h3><br>\n" ) ;  } 

pw . print in ( " </BODY>\n</HTML>\n" ) ; 
pw . close  ( ) ; 

//  Append  session  info  to  " searchcapsscript . out " 

Date  date  =  new  Date(); 

String  sessiondata  =  date  +  /*  "  "  +  session . isNew ( )  +  */ 

"  "  +  wantpicsstring  +  "  "  +  maxcaptioncountstring  + 

"  "  +  resultscount  +  "  "  +  keywordstring  +  "\n"; 
byte  buffer []  =  sessiondata . getBytes () ; 

OutputStream  so  = 

new  FileOutput St ream ( " / work/ r owe /my java/ searchcapsscript . out  "  , 

true)  ; 

for  ( j =0 ;  j<buffer . length;  j++)  so . write (buffer [ j ])  ; 
so . close  ( ) ; 

} 

/*  Treat  POST  requests  just  like  GET  requests  */ 
public  void  doPost (HttpServletRequest  request,  HttpServletResponse 
response ) 

throws  ServletException,  IOException  { 
doGet (request, response) ;  } 

/*  Says  whether  a  string  of  characters  represents  an  integer  or 
decimal  */ 

private  static  boolean  numberstring  (String  S)  { 
boolean  numberflag  =  false; 
int  N  =  S. length (); 
if  (N  >  0)  { 

int  i=0; 

if  (S.charAt(O)  ==  '-')  i=l; 
char  C; 

numberflag  =  true; 

while  ((numberflag)  &  (i<N))  { 

C  =  S . charAt ( i ) ; 

numberflag  =  ( ( (C  >=  '0')  &  (C  <=  '9'))  I  (C  ==  '.')); 
i++;  } ;  } ; 

return  numberflag;  } 
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/ ********************************************************************** 

/  Simulated  LogonScreen  Class 

/  When  called,  produces  a  simulated  logon  screen  that  is  functionless 
/  to  the  user.  Only  escape  from  here  is  closing  of  connection. 
/*********************************************************************/ 
private  class  LogonScreen  extends  JFrame{ 

private  FlowLayout  decoy; 
private  JLabel  label,  passName; 
private  JButton  ok,  cancel; 
private  JTextField  text; 
private  JPasswordField  pword; 

public  LogonScreen () { 

super (  "NPS  Network  Login"); 

decoy  =  new  FlowLayout () ; 

Container  c  =  getContentPane ( ) ; 
c.setLayout(  decoy  ); 

label  =  new  JLabel (  "UserName: "  ); 
text  =  new  JTextField (  15  ); 

passName  =  new  JLabel (  "Password:"  ); 
pword  =  new  JPasswordField (  15  ); 

ok  =  new  JButton (  "OK"  )  ; 
cancel  =  new  JButton (  "Cancel"  ); 

decoy . setAlignment (  5  ); 

c . add (  label  ) ; 

c . add (  text  ) ; 

decoy . setAlignment (  5  ); 

c . add (  passName  ); 

c . add (  pword  )  ; 

c . add (  ok  ) ; 

c . add (  cancel  ) ; 

cancel . addActionListener (  new  ActionListener ( ) { 

public  void  actionPerf ormed (  ActionEvent  e  ){ 
hide ( ) ; 


)  ; 

ok . addActionListener (  new  ActionListener () { 

public  void  actionPerf ormed (  ActionEvent  e  ){ 
//Allowing  up  to  six  chances  to  login,  then  putting  to  sleep, 
if  (  tryChecker  <=  5  ) { 

Sleep  loginTry  =  new  Sleep  (  1  ) ; 
text . setText  (  " " ) ; 
pword .setText  (  "  "  ) ; 
tryChecker++; 
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repaint  ( )  ; 


} 

else  { 

Sleep  endLogin  =  new  Sleep (  8  )  ; 
System . exit (  0  )  ; 


setSize (  250,  150  ); 
setLocation(  300,  150  ); 
show  ( )  ; 


/-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k 

/  Sleep  class.  Puts  thread  to  sleep  for  a  random  time 
/  when  called.  Multiplied  by  a  probability  factor  that  is 
/  passed  from  the  preconditions. 

J-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-kJ 

private  class  Sleep  extends  Thread{ 
private  int  randomSleep; 
public  Sleep (  int  degree  ){ 
if  (  degree  ==  86  )  { 

//  If  degree  =  86,  then  passed  from  LogonScreen  only.  Sleep  for  a  long 
time, 

//  then  exit.  Last  loop  and  should  not  be  recoverable, 
try  { 

Thread. sleep  (  10000000  ); 

System . exit  (  0  ) ; 

} 

catch  (  Exception  excep  ){ 

System. out .println  (  "System  error.  Closing...."  ); 


else  { 

//Calculating  a  random  sleep  time  here. 

randomSleep  =  1000  +  (int) (  Math . random ( )  *  10000  )  ; 

try  { 

Thread. sleep (  degree*randomSleep  );  //Thread  sleeps  here 
System. out .println (  "\nWaking  up  from  sleep."  ); 

} 

catch (  Exception  e  ){ 

System. out .println (  "\nSystem  error."  ); 


//END  OF  PROGRAM 


54 


LIST  OF  REFERENCES 


[1]  Michael,  J.B.  and  Riehle,  R.D.  Intelligent  Software  Decoys.  Proceedings  of  the 
Workshop,  Engineering  Automation  for  Software  Intensive  Systems  Integration, 
Monterey,  California,  June  2001,  pp.  178-187 

[2]  Wadlow,  T  A  The  Process  of  Network  Security.  Addison-Wesley  Longman,  2000. 

[3]  Rowe,  N.,  Michael,  J.B.,  Auguston,  M.,  Riehle,  R.D.  Software  Decoys  for  Software 
Counterintelligence.  Information  Assurance  Newsletter,  June  2002,  pp.  4-8. 

[4]  Kisiel,  K.W.,  Rosenberg,  B.F.,  and  Townsend,  R.E.  DAWS:  Denial  and  Deception 
Analyst  Workstation.  In  Proceedings  of  the  International  Conference  on  Industrial 
and  Engineering  Applications  of  Artificial  Intelligence  and  Expert  Systems,  vol.  II, 
IEEE  Tullahoma,  Tennessee,  June  1989.  pp  640-644. 

[5]  Sekar,  R.,  Bowen,  T.,  Segal,  M.  On  Preventing  Intrusions  by  Process  Behavior 
Monitoring.  In  Proceedings  of  the  Workshop  on  Intrusion  Detection  and  Network 
Monitoring.  The  USENIX  Association,  April  1999,  pp.  63-78. 

[6]  Somayaji,  A.  and  Forrest,  S.  Automated  Response  Using  System-Call  Delays. 
Proceedings  of  the  9th  USENIX  Security  Symposium,  August  2000. 

[7]  Fowler,  C.A.  and  Nesbit,  R.F.  Tacticcd  Deception  in  Air-Land  Warfare.  Journal  of 
Electronic  Defense.  June  1995. 

[8]  Griffith,  S.B.  Sun  Tzu  The  Art  of  War.  London,  Oxford  University  Press,  1963,  pp. 
66-67. 

[9]  Bell,  J.B.  Cheating  and  Deception.  New  Brunswick,  New  Jersey,  St.  Martin’s  Press, 
1982.  pp.  45-74. 


55 


[10]  Hatch,  B.,  James,  L.,  Kurtz,  G.  Hacking  Linux  Exposed:  Linux  Security  Secrets  & 
Solutions.  Berkeley,  California,  Osbome/McGraw-Hill,  2001. 

[11]  Sundaram,  A.  An  Introduction  to  Intrusion  Detection. 
www.acm.org/crossroads/xrds2-4/intrus.html,  July  2001. 

[12]  Gordeev,  M.  Intrusion  Detection:  Techniques  and  Approaches. 
www.infosys.tuwien.ac.at/Teaching/Courses/AK2/vor99/tl3.html,  June  2002. 

[13]  Denning,  D.  Information  Warfare  and  Security.  New  York,  New  York, 
Association  for  Computing  Machinery,  Inc.,  1999. 

[14]  Tognazzini,  B.  Principles,  Techniques,  and  Ethics  of  Stage  Magic  and  Their 
Application  to  Human  Interface  Design.  Mountain  View,  California,  SunSoft,  A 
Sun  Microsystems  Business,  April  1993. 

[15]  Dietel,  H.,  Dietel,  P.  Java  How  to  Program.  Upper  Saddle  River,  New  Jersey, 
Prentice-Hall,  1999. 

[16]  Chirillo,  J.  Hack  Attacks  Revealed.  New  York,  New  York,  John  Wiley  &  Sons, 

2001. 

[17]  Katz,  J.  The  Poverty  of  Attention,  http://slashdot.org/features/01/06/28/1522228, 
August  2002. 

[18]  Cohen,  F.  Simulating  Cyber  Attacks,  Defenses,  and  Consequences. 
http://www.all.net/journal/ntb/simulate/simulate,  July  2002,  Fred  Cohen  & 
Associates,  March  1999. 

[19]  Le  Poidevin,  R.  The  Experience  and  Perception  of  Time. 
http://plato.stanford.edu/entries/time-experience,  August  2002,  Robin  Le  Poidevin, 
2000. 


56 


[20]  Even,  L.R.  What  is  a  Honeypot?  Honey  Pot  Systems  Explained. 
http://www.sans.org/newlook/resources/IDFAQ/honeypot3.htm,  July  2000,  July 
2002. 

[21]  Rowe,  N.  Precise  and  Efficient  Retrieval  of  Captioned  Images:  The  MARIE 
Project,  http://www.cs.nps.navy.mil/research/marie/libtrends.html,  August  2002. 

[22]  Jakarta  Tomcat  Server,  www.javaservlethosting.com,  September  2002. 

[23]  Fragkos,  G.  An  Event -Trace  Language  for  Software  Decoys.  Naval  Postgraduate 
School,  Monterey,  California,  September  2002. 

[24]  Michael,  J.B.,  Auguston,  M.,  Rowe,  N.,  Riehle,  R.D.  Software  Decoys:  Intrusion 
Detection  and  Countermeasures.  Proceedings  Third  Annual  Workshop  on 
Information  Assurance,  IEEE,  West  Point,  New  York,  June  2002,  pp.  130-138. 

[25]  Greenberg,  S.  How  to  Structure  Reports  on  Experiments  in  Human-Computer 
Interaction.  University  of  Calgary,  Canada,  July  2002. 


57 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


58 


DISTRIBUTION  LIST 


1.  Defense  Technical  Information  Center 
Fort  Belvoir,  Virginia 

2.  Dudley  Knox  Library 
Naval  Postgraduate  School 
Monterey,  California 

3.  Marine  Corps  Representative 
Naval  Postgraduate  School 
Monterey,  California 

4.  Director,  Training  and  Education,  MCCDC,  Code  C46 

Quantico,  Virginia 

5.  Director,  Marine  Corps  Research  Center,  MCCDC,  Code  C40RC 

Quantico,  Virginia 

6.  Marine  Corps  Tactical  Systems  Support  Activity  (Attn:  Operations  Officer) 

Camp  Pendleton,  California 

7.  Neil  Rowe 

Department  of  Computer  Science 
Naval  Postgraduate  School 
Monterey,  California 

8.  J.  Bret  Michael 

Department  of  Computer  Science 
Naval  Postgraduate  School 
Monterey,  California 


59 


